Deploying Enhanced NAT Services in GPRS Networks

Application Note

Deploying Enhanced NAT Services in GPRS Networks Mitigating Overbilling Attack

Ariff Premji

Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408 745 2000 or 888 JUNIPER www.juniper.net Part Number: 350076-001

Mitigating Overbilling Attack

Contents

Contents.............................................................................................................................. 2 Executive Summary............................................................................................................ 3 Deployment Considerations ............................................................................................... 4

Offline or Port-mirrored Gn Firewall Deployments...................................................... 6 Enabling Port-mirroring on a Juniper Networks M-series Router ....................... 6

High-Availability Configurations for the Gi NAT Firewall .................................................... 7 NSRP Configuration on Primary Gi NAT Firewall....................................................... 8 NSRP Configuration on Secondary Gi NAT Firewall.................................................. 8 Interface Configuration for the Gi NAT NS5200 Firewall............................................ 9

Basic Interface Configuration.............................................................................. 9 Aggregated Ethernet Interface Configuration ..................................................... 9 Defining NAT Pools on “Untrust” Interface(s) ................................................... 10 NAT Policies...................................................................................................... 10 Terminating NAT Sessions Using NSGP.......................................................... 10

Basic Troubleshooting ...................................................................................................... 12

2 Copyright © 2005, Juniper Networks, Inc.


Executive Summary As mobile operators extend the reach of public and private data networks to all wireless devices, it becomes important to ensure that network resources owned by wireless operators are secured and efficiently utilized. Most mobile operators use traditional network address translation (NAT) solutions in their General Packet Radio Service (GPRS) network to grant subscribers access to public and private data networks. These legacy NAT solutions lack certain features important to modern wireless networks. High availability and security features such as session mirroring and intelligent session purging are examples of features legacy systems typically lack.

This document provides an overview of how Juniper Networks Netscreen firewall products can be deployed in a typical GPRS Gi network to provide enhanced NAT services. This solution also addresses a common attack known as the overbilling attack whereby subscribers get charged for unwanted data downloads.

A sample topology will be used for which relevant configuration snippets will be provided. Configurations for a Gi NAT firewall, Gn firewall, and a port-mirroring router will be discussed. A Netscreen 5200 will be used as the Gi NAT firewall whereas a Netscreen 500 will be used as a Gn firewall.

This document should not be considered a replacement for the Juniper Networks technical manuals. For detailed information on these products, please visit http://www.juniper.net/techpubs/.

Copyright © 2005, Juniper Networks, Inc. 3

http://www.juniper.net/techpubs/


Deployment Considerations Mobile operators typically deploy their gateway GPRS support nodes (GGSN) in areas of the network where public/private access nodes are most concentrated. Having the GGSNs co-located next to public/private access nodes allows the operator to easily interface with these external networks. Access to public networks usually requires some form of network address translation (NAT) depending on the service the mobile subscriber requires. However, traffic from mobile subscribers destined to private networks is not usually subject to NAT. Figure 1 shows how GSN nodes reside in a typical GPRS network.

Figure 1: GSN nodes in a typical GPRS network

Juniper Networks Netscreen 5200/5400/ISG firewalls can be used in the Gi network to provide high-performance NAT services while securing the GRPS network, whereas the Netscreen 500/ISG GPRS firewalls are used in the Gn network to secure the GSN network against malicious activity. The Netscreen Gn GRPS firewalls can be used for various security applications. However, the scope of this document will be limited to the role these GPRS firewalls play in deploying an enhanced NAT service. The GPRS Gn firewall creates and maintains GTP session-state as GTP packets are intercepted between the SGSN and GGSN nodes. The GPRS firewall can provide other GTP-aware security solutions, as well. These additional security solutions are discussed in the white paper titled “GPRS Security Threats and Solution Recommendations.” Since the Netscreen Gn firewall is GTP session ‘aware,’ it can immediately detect when a mobile data user detaches from the wireless network. When mobile subscribers terminate their data sessions, the Gn firewall uses a control protocol, Netscreen Security Gateway Protocol (NSGP), to alert the Netscreen NAT firewall in the



Gi network. A NSGP communication channel must therefore exist between the firewalls in the Gn and Gi networks.

The Gi NAT firewalls purge individual NAT sessions as GTP sessions for a particular subscriber are cleared on the Gn firewall. The purging of individual NAT sessions mitigates a well-known security issue known as the ‘overbilling attack,’ whereby a mobile user gets charged for data downloads initiated by the previous user of that particular source IP address.

Figure 2 below shows how the Gi and Gn firewalls connect to a Layer 2 Ethernet switch in the sample topology. This Ethernet switch has been configured with two VLANs; a Gi VLAN, which will be used for GGSN traffic, and a NSGP VLAN, which provides a path for the NSGP communication between the Gi and Gn firewalls.

Figure 2: Using an Ethernet switch to provide the NSGP path between the Gi and Gn Firewalls

Although the example above uses an Ethernet switch to provide the NSGP path between the Gn and Gi firewalls, a separate routed path could have been used considering that NSGP uses IP transport. The Gn firewall in this example is configured in Layer 3 or ‘route’ mode. Netscreen firewalls can also operate in Layer 2 mode.



Offline or Port-mirrored Gn Firewall Deployments The Gn firewall needs to be in the data path of GTP packets so that it can be ‘aware’ of a user’s GTP state. Most operators deploy the Gn firewall in this configuration. However, operators may deploy the Gn firewall outside the Gn network if they do not want a firewall in the Gn network or if they choose to gradually introduce the Gn firewall after a pre-deployment trial period. Mobile operators that use Juniper Networks M-series routers in their network can take advantage of the JUNOS “port-mirroring” feature to accomplish this. The following example provides configuration snippets for cases in which the Gn firewall is not installed in the Gn network. Instead, the Gn firewall receives mirrored GTP packets from a Juniper Networks M-series router in the Gn data path.

Enabling Port-mirroring on a Juniper Networks M-series Router

The following JUNOS configuration can be added to an M-series router to activate port mirroring. In this example, port ge-7/0/9 connects to the Gn firewall.

forwarding-options { port-mirroring { input { family inet { rate 1; } } output { interface ge-7/0/9.0 { next-hop 88.88.88.2; } } } } interfaces { ge-7/0/9 { vlan-tagging; unit 0 { vlan-id 500; family inet { address 88.88.88.1/30; } } } }



A JUNOS firewall filter is used to ensure that only GTP v0 and v1 packets are mirrored. This firewall filter is then applied on the router’s GN interface (preferably the interface that is facing the GGSNs). It is important to ensure that the router mirrors all GTP packets so that the Gn firewall can create proper GTP state.

firewall { filter GTP-MIRROR { term t1 { from { protocol [ udp tcp ]; destination-port [ 3386 2123 2152 ]; } then { count GTP-MIRRORED-PKTS; port-mirror; accept; } } } } ge-7/0/0 { unit 0 { family inet { filter { input GTP-MIRROR; output GTP-MIRROR; } address 3.3.3.2/30; } } } }

High-Availability Configurations for the Gi NAT Firewall High-availability in wireless data services is considered essential since re-transmissions across wireless media can be both costly and time-consuming. The ScreenOS feature known as Netscreen Security Redundancy Protocol (NSRP) provides high availability when used between Gi NAT firewalls. The example described below is for an active/standby high-availability configuration in the Gi network. This setup allows the standby firewall to mirror sessions established on the active device to maintain traffic flow in the event that the primary device fails. High-availability configuration can also be applied to the firewalls in the Gn network. It may be important to ‘track’ certain interfaces so as to ensure that the correct firewall maintains mastership. For example, if the Internet-facing interface on the primary firewall fails; the standby firewall should assume mastership. Netscreen firewalls issue gratuitous ARPs during mastership changes, which give the attached Layer 2 Ethernet devices an opportunity to update their MAC address forwarding tables.

Netscreen firewalls can be deployed in either active/standby or active/active modes. In this example, we use an active/standby configuration on the Gi NAT firewall. The Netscreen 5200/5400 Gi firewalls have dedicated interfaces, labeled ‘ha1’ and ‘ha2’, which are used to mirror session state and to determine device mastership.



NSRP Configuration on Primary Gi NAT Firewall The following configuration activates NSRP on the primary device. The primary device is configured with a lower priority number (preferable device). Two interfaces, Ethernet2/1 and Ethernet2/5, are tracked so that NSRP mastership can switch in the event that either one of these interfaces fail.

ns5200-> set nsrp cluster id 1 ns5200-> set nsrp rto-mirror sync ns5200-> set nsrp vsd-group id 0 priority 50 ns5200-> set nsrp vsd-group id 0 monitor interface ethernet2/5 weight 255 ns5200-> set nsrp vsd-group id 0 monitor interface ethernet2/1 weight 255

NSRP Configuration on Secondary Gi NAT Firewall A similar configuration is applied to the backup. A higher priority number is chosen to ensure that this device is the backup firewall.

ns5200-> set nsrp cluster id 1 ns5200-> set nsrp rto-mirror sync ns5200-> set nsrp vsd-group id 0 priority 100 ns5200-> set nsrp vsd-group id 0 monitor interface ethernet2/5 weight 255 ns5200-> set nsrp vsd-group id 0 monitor interface ethernet2/1 weight 255

After applying the NSRP configuration, the CLI prompts on the active and standby units should read “(M)” and “(B),” respectively, representing the master and backup states. Configuration changes applied to the active device are automatically applied on the backup device, as well. System and management configuration must be applied to each individual device.



Interface Configuration for the Gi NAT NS5200 Firewall ScreenOS requires that interfaces belong to a ‘zone’ before any IP attributes can be applied. The following examples show how the gigabit Ethernet interfaces can be configured in both aggregate and non-aggregate mode (802.3ad). Ethernet interfaces 2/1 to 2/2 will be used for traffic received from the mobile users whereas interfaces 2/5 to 2/6 will be Internet facing. This allows for both onboard GigaScreen ASICs to be used on the NS5200/5400. For more information on the NS5200 system architecture, refer to the Netscreen Firewall Appliance documentation at http://www.juniper.net/techpubs/

Basic Interface Configuration

The following commands are used to configure the IP address of interfaces e2/1 and e2/5. All IP services except ICMP are disabled on these interfaces.

ns5200-> set interface ethernet2/1 zone Trust ns5200-> set interface ethernet2/1 ip 10.10.10.1/16 ns5200-> set interface ethernet2/1 route ns5200-> unset interface ethernet2/1 manage ns5200-> set interface ethernet2/1 manage ping ns5200-> set interface ethernet2/5 zone Untrust ns5200-> set interface ethernet2/5 ip 172.16.1.1/24 ns5200-> set interface ethernet2/5 route ns5200-> unset interface ethernet2/5 manage ns5200-> set interface ethernet2/5 manage ping

Aggregated Ethernet Interface Configuration

When the need for aggregated Ethernet arises, the following commands can be used to bundle interface e2/1-e2/2 and e2/5-e2/6 as aggregated interfaces “agg1” and agg2.”

set interface id 100 "aggregate1" zone "Trust" set interface id 101 "aggregate2" zone "Untrust" set interface ethernet2/1 aggregate aggregate1 set interface ethernet2/2 aggregate aggregate1 set interface ethernet2/5 aggregate aggregate2 set interface ethernet2/6 aggregate aggregate2 set interface aggregate1 ip 10.10.10.1/16 set interface aggregate2 ip 172.16.1.1/24 unset interface agg1 manage unset interface agg2 manage set interface agg1 manage ping set interface agg2 manage ping


http://www.juniper.net/techpubs/


Defining NAT Pools on “Untrust” Interface(s)

The following example shows the commands used to configure a fixed-port NAT pool with 254 public addresses on the Untrust interface e2/5. One of these addresses is used as the extended IP address on e2/5.

ns5200-> set interface ethernet2/5 ext ip 172.17.1.1 255.255.255.0 dip 4 172.17.1.2 172.17.1.254 fix-port If more NAT pools are required, additional DIP pools can be added to e2/5. The following example shows two class-B public pools being added as DIP pool-id 5 and DIP pool-id 6. These DIP pools are later referenced by policies that determine the source addresses of the traffic that needs to be translated.

ns5200-> set interface ethernet2/5 ext ip 172.16.0.1 255.255.0.0 dip 5 172.16.0.2 172.16.255.254 fix-port ns5200-> set interface ethernet2/5 ext ip 172.17.0.1 255.255.0.0 dip 6 172.17.0.2 172.17.255.254 fix-port

NAT Policies

A policy is used to choose the source address of the traffic that will be translated. An address-book entry is defined and then referenced in the policy.

ns5200-> set address "Trust" "10.0.0.0/8" 10.0.0.0 255.0.0.0

ns5200-> set policy id 1 from "Trust" to "Untrust" "10.0.0.0/8" "Any" "ANY" nat src dip-id 4 permit

Terminating NAT Sessions Using NSGP

Netscreen Gatekeeper (NSGP) protocol is used between the Gn and Gi firewalls to keep track of terminated data sessions so that per-user NAT sessions can be torn down in the Gi firewall. NSGP configurations are required on both the Gn firewall and Gi firewall as shown below.

On the Gi firewall, the following commands enable NSGP on interface e2/2. Other IP services may be disabled on this interface. The interface that receives NSGP messages has been placed in a zone named “NSGP”. The default TCP port for NSGP is 12521.

ns5200-> set zone NSGP ns5200-> set interface ethernet2/2 zone NSGP ns5200-> set interface ethernet2/2 ip 172.16.10.1/24 ns5200-> set interface ethernet2/2 nsgp ns5200-> set nsgp md5-authentication nsgp!password ns5200-> set nsgp context 100 type session zone NSGP

The Gn firewall has 2 logical interfaces: e2/1.1, which receives mirrored GTP packets; and e2/1.2, which is used to transmit the NSGP messages.

set interface "ethernet2/1.1" tag 500 zone "Trust" set interface "ethernet2/1.2" tag 501 zone "Trust" set interface ethernet2/1.1 ip 88.88.88.2/24 set interface ethernet2/1.2 ip 172.16.10.2/30 set gtp configuration ENAT



set log traffic-counters set log forwarded basic set log state-invalid basic set log prohibited basic set log tunnel-limited basic set notify 172.16.10.1 src-interface ethernet2/1.2 context 100 md5-authentication nsgp!password exit set nsgp md5-authentication nsgp!password set nsgp context 100 type session zone Trust

In this example, the Gn firewall is not in the Gn data path. Hence, the mirrored packets still need to enter and leave the Gn firewall so that the GTP session state can be established. This is accomplished by redirecting incoming packets out of the same e2/1.1 interface to a dummy gateway address. The gateway address used in this example is 88.88.88.254.

set arp 88.88.88.254 deadbeef0001 "ethernet2/1.1" set policy id 1 from "Trust" to "Trust" "Any" "Any" "ANY" permit log set policy id 1 gtp ENAT set route 172.0.0.0/8 interface mgt gateway 172.20.33.1 set route 192.0.0.0/8 interface mgt gateway 172.20.33.1 set route 0.0.0.0/0 interface ethernet2/1.1 gateway 88.88.88.254



Acknowledgments

The author would like to acknowledge the contribution provided by the following people:

Stefan Brunner, Professional Services – Juniper Networks.

Akhlaq Ali, Technical Marketting Engineer – Juniper Networks

Copyright © 2005, Juniper Networks, Inc. All rights reserved. Juniper Networks and the Juniper Networks logo are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks in this document are the property of Juniper Networks or their respective owners. All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

Basic Troubleshooting A few ‘show’ commands and basic system debugging can be used to ensure that NSGP has been configured correctly.

The get gtp tunnels shows the active tunnels in the Gn firewall.

ns500-> get gtp tunn Activated 1 tunnels, maximum 150000 allowed. idx 83, nsapi 5 in 466 out 788 u4 c5 i80 state 2, time 1440m user 172.16.1.237,75906be -> 172.16.7.1,0021405, path 1f next 0 ctrl 172.16.1.237,001439 -> 172.16.1.237,00278, path 11 next 53 Total 1 tunnels shown. ns500->

Debugging may also be enabled on the Gi NAT firewall to see if NSGP messages are clearing NAT sessions. The following debug output shows that sessions for user 10.0.0.52 were cleared as a result of NSGP (whose context-id is 100).

ns500-> deb nsgp basic ns500-> get db stream ## 18:15:53 : add msg len 16 type 4-clr-sess xid 0x0c9cd728 : ctxid 100 clr-IP 10.0.0.52 ## 18:15:54 : del msg len 16 type 4-clr-sess xid 0x0c9cd728 : ctxid 100 clr-IP 10.0.0.52 ns500->

For more information and additional commands, refer to the GPRS Reference Guide.


Documents

Deploying Enhanced NAT Services in GPRS Networks