MMS protection profiles

MMS protection profiles

An MMS protection profile is a group of settings that you can apply to an MMS session matched by a security policy.

MMS protection profiles are easy to configure and can be used by more than one security policy. You can configure a single MMS protection profile for the different traffic types handled by a set of security policies that require identical protection levels and types. This eliminates the need to repeatedly configure those same MMS protection profile settings for each individual security policy.

For example, while traffic between trusted and untrusted networks might need strict protection, traffic between trusted internal addresses might need only moderate protection. You would configure two separate MMS protection profiles to provide the different levels of protection: one for traffic between trusted networks, and one for traffic between trusted and untrusted networks.

Once you have configured the MMS Protection Profile, you need to add it to a security policy to apply the profile to MMS traffic.


Bypassing MMS protection profile filtering based on carrier endpoints

You can use carrier endpoint filtering to exempt MMS sessions from MMS protection profile filtering. Carrier endpoint filtering matches carrier endpoints in MMS sessions with carrier endpoint patterns. If you add a carrier endpoint pattern to a filter list and set the action to exempt from all scanning, all messages from matching carrier endpoints bypass MMS protection profile filtering. See Bypassing message flood protection based on user’s carrier endpoints.


Applying MMS protection profiles to MMS traffic

To apply an MMS protection profile you must first create the MMS protection profile and then add the MMS protection profile to a security policy by enabling the Carrier security profile. The MMS protection profile then applies itself to the traffic accepted by that security policy.

MMS protection profiles can contain settings relevant to many different services. Each security policy uses the subset of the MMS protection profile settings that apply to the sessions accepted by the security policy. In this way, you might define just one MMS protection profile that can be used by many security policies, each policy using a different or overlapping subset of the MMS protection profile.


To add an MMS protection profile to a security policy

1. Go to Security Profiles > MMS Profile.

2. Select Create New to add an MMS protection profile.

3. Configure as needed, and save.

4. Go to Policy & Objects > IPv4 Policy.

5. Select Create New to add a security policy, or select an existing policy and Edit to add the MMS profile.

6. Configure the security policy as required.

7. Enable MMS Profile, and select the MMS profile to add to the security policy.

8. Select OK.



GTP basic concepts

GPRS currently supports data rates from 9.6kbps to more than 100 kbps, and is best suited for burst forms of traffic. GPRS involves both radio and wired components. The mobile phone sends the message to a base station unit (radio based), and the base station unit sends the message to the carrier network and eventually the Internet (wired carrier network).

The network system then either sends the message back to a base station and to the destination mobile unit, or forwards the message to the proper carrier’s network where it gets routed to the mobile unit.


PDP Context

The packet data protocol (PDP) context is a connection between a mobile station and the end address that goes through the SGSN and GGSN. It includes identifying information about the mobile customer used by each server or device to properly forward the call data to the next hop in the carrier network, typically using a GTP tunnel between the SGSN and GGSN.

When a mobile customer has an active voice or data connection open, both the SGSN and GGSN have the PDP context information for that customer and session.

When a mobile phone attempts to communicate with an address on an external packet network, either an IP or X.25 address, the mobile station that phone is connected to opens a PDP context through the SGSN and GGSN to the end address. Before any traffic is sent, the PDP context must first be activated.

The information included in the PDP context includes the customer’s IP address, the IMSI number of the mobile handset, and the tunnel endpoint ID for both the SGSN and GGSN. The ID is a unique number, much like a session ID on a TCP/IP firewall. All this information ensures a uniquely identifiable connection is made.

Since one mobile device may have multiple connections open at one time, such as data connections to different Internet services and voice connections to different locations, there may be more than one PDP context with the same IP address making the extra identifying information required.

The endpoint that the mobile phone is connecting to only knows about the GGSN — the rest of the GPRS connection is masked by the GGSN.

Along the PDP context path, communication is accomplished in using three different protocols.

  • The connection between the Mobile Station and SGSN uses the SM protocol.
  • Between SGSN and GGSN GTP is used.
  • Between GGSN and the endpoint either IP or X.25 is used.

FortiOS Carrier is concerned with the SGSN to GGSN part of the PDP context — the part that uses GTP. For more about PDP context, see Tunnel Management Messages.

Creating a PDP context

While FortiOS Carrier is concerned mostly with the SGSN to GGSN part of the PDP Context, knowing the steps involved in creating a PDP context helps understand the role each device, protocol, and message type plays.

Both mobile stations and GGSNs can create PDP contexts.


A Mobile Station creates a PDP context

1. The Mobile Station (MS) sends a PDP activation request message to the SGSN including the MS PDP

address, and APN.

2. Optionally, security functions may be performed to authenticate the MS.

3. The SGSN determines the GGSN address by using the APN identifier.

4. The SGSN creates a downlink GTP tunnel to send IP packets between the GGSN and SGSN.

5. The GGSN creates an entry in its PDP context table to deliver IP packets between the SGSN and the external packet switching network.

6. The GGSN creates an uplink GTP tunnel to route IP-PDU from SGSN to GGSN.

7. The GGSN then sends back to the SGSN the result of the PDP context creation and if necessary the MS PDP


8. The SGSN sends an Activate PDP context accept message to the MS by returning negotiated the PDP

context information and if necessary the MS PDP address.

9. Now traffic can pass from the MS to the external network endpoint.


A GGSN creates a PDP context

1. The network receives an IP packet from an external network.

2. The GGSN checks if the PDP Context has already been created.

3. If not, the GGSN sends a PDU notification request to the SGSN in order to initiate a PDP context activation.

4. The GGSN retrieves the IP address of the appropriate SGSN address by interrogating the HLR from the IMSI identifier of the MS.

5. The SGSN sends to the MS a request to activate the indicated PDP context.

6. The PDP context activation procedure follows the one initiated by the MS. See “A Mobile Station creates a PDP context”.

7. When the PDP context is activated, the IP packet can be sent from the GGSN to the MS.


Terminating a PDP context

A PDP context remains open until it is terminated. To terminate the PDP context an MS sends a Deactivate PDP context message to the SGSN, which then sends a Delete PDP Context message to the GGSN. When the SGSN receives a PDP context deletion acknowledgment from the GGSN, the SGSN confirms to the MS the PDP context deactivation. The PDP can be terminated by the SGSN or GGSN as well with a slight variation of the order of the messages passed.

When the PDP Context is terminated, the tunnel it was using is deleted as well. If this is not completed in a timely manner, it is possible for someone else to start using the tunnel before it is deleted. This hijacking will result in the original customer being overbilled for the extra usage. Anti-overbilling helps prevent this. See Configuring Anti-overbilling in FortiOS Carrier.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

This entry was posted in FortiOS 5.4 Handbook and tagged , , on by .

About Mike

Michael Pruett, CISSP has a wide range of cyber-security and network engineering expertise. The plethora of vendors that resell hardware but have zero engineering knowledge resulting in the wrong hardware or configuration being deployed is a major pet peeve of Michael's. This site was started in an effort to spread information while providing the option of quality consulting services at a much lower price than Fortinet Professional Services. Owns PacketLlama.Com (Fortinet Hardware Sales) and Office Of The CISO, LLC (Cybersecurity consulting firm).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.