Application Assurance — GTP Roaming Firewall
This chapter describes Application Assurance GTP roaming firewall.
Topics in this chapter include:
Applicability
The configuration and information in this chapter are based on SR OS Release 20.2.R2.
Overview
Wireless network operators rely on GPRS Tunneling Protocol (GTP) for the delivery of mobile data services across the access network. However, GTP is not designed to be secure, exposing the mobile access network to attacks from both its own subscribers and its partner networks.
The Application Assurance (AA) SR OS 20.2.R2 firewall feature extends AA-Integrated Service Adapter (AA-ISA) application-level analysis to provide an in-line stateful service that integrates into a 7750 Service Router. The feature provides protection for mobile operator infrastructure against attacks from compromised mobile gateways: Serving Gateways (SGWs) or Packet data network Gateways (PGWs).
AA stateful packet filtering, combined with AA L7 classification and control, provides operators with advanced, next-generation firewall (FW) functionality. This AA stateful FW feature runs on AA-ISA and, using stateful inspection, not only inspects packets at Layers 3 to 7, but also monitors and keeps track of the connection state. AA GTP roaming FW deployment shows an example AA GTP roaming FW deployment.
S8/Gp AA FW deployment
AA FW is deployed as a GTP FW on S8/Gp (or S5/Gn) interfaces, either as part of a 7750 SR router in the form of an AA-ISA hardware module or as a separate Virtual SR (VSR) appliance. AA FW provides operators with network security, such as:
GTP protocol validation, which checks for anomaly attacks that involve malformed, corrupt, or spoofed traffic:
header length checks
Information Element (IE) length validation
invalid reserved field validation
reserved IE validation
missing mandatory IE validation
sequence number validation
Tunnel Identification (TEID) validation - blocks GTP tunnel creations that have not been signaled correctly
PGW and SGW redirection protection
GTP-in-GTP check
Handover control to prevent session hijacking
Source address (User Equipment (UE)) anti-spoofing protection
Protection against unauthorized Public Land Mobile Network (PLMN) and/or Access Point Name (APN) access:
filter message-based APN, International Mobile Subscriber Identity (IMSI) prefix
Protection against unsupported GTP message types:
filter messages, based on message types and/or message length
Protection against flooding attack:
GTP traffic bandwidth policing, which limits the GTP bandwidth from a roaming partner SGW/PGW
GTP tunnel limiting, which limits the number of concurrent GTP tunnels and/or the setup rate of these tunnels from a roaming partner SGW/PGW
Protection against IP fragmentation-based attacks:
drop rules for IP fragmentation of GTP messages
AA FW supports both GTPv1 and GTPv2. It is typically deployed as an L3/VPRN service. SAPs/spokes are diverted to AA for a GTP FW. L2/VPLS connectivity is supported by AA. AA transit subscribers (identified by SGW IPs) are auto-created under the parent-diverted SAPs/spokes.
UE IP address anti-spoofing
Source address spoofing is initiated by a malicious UE that hijacks (spoofs) an IP address of another UE and invokes a download from a malicious server on the Internet. After the download begins, the malicious UE exits the session. The UE under attack (receiving the download traffic) gets charged for traffic it did not solicit.
AA FW associates the GTP-c messages of the UE IP address IE with the GTP-u packets to ensure that the packets carried in the upstream have the correct source IP address (inner IP within the GTP-u tunnel). Because the UE address is negotiated within the PDP context creation handshake, any packets originating from the UE that contain a different source address are detected by AA FW and dropped.
To enable UE IP address anti-spoofing protection, the operator needs to enable "validate-source-ip-addr", as follows:
*A:Dut-C>config>app-assure>group>
+---gtp-filter <gtp-filter-name> [create]
| +---gtp-tunnel-database
| +---validate-source-ip-addr
GTP TEID validation
Compromised mobile gateways (GSNs) can send storms of GTP traffic with invalid GTP TEIDs to cause a denial of service (DoS) attack. By inspecting GTP-c messages, AA FW supports stateful correlation of upstream and downstream GTP flows (DstIP + TEID) of the same PDN session. AA drops packets with TEIDs that have not been negotiated correctly.
The operator can enable AA to drop GTP traffic with an invalid TEID using:
*A:Dut-C>config>app-assure>group>
+---gtp-filter <gtp-filter-name> [create]
| +---gtp-tunnel-database
| +---validate-gtp-tunnels
GTP anomaly prevention/sequence number checks
Protocol anomaly attacks involve malformed or corrupt packets that typically fall outside of the protocol specifications. Packets are denied by AA FW if they fail the sanity check. The following are some examples of GTP sanity checks:
invalid GTP header length
invalid IE length
invalid reserved fields
invalid sequence number
missing mandatory IEs
Also, AA FW performs sequence number validation whereby it ensures no out-of-sequence GTP packets. By default, sequence number validation is disabled. To enable it, the following CLI command can be used:
GTP packets with wrong sequence numbers are dropped when validate-sequence-number is enabled.
GTP message-type filtering
AA FW performs GTP message validation, in which packets with invalid message types (that are not applicable to the roaming interfaces) are denied by the AA GTP-c inspection command:
GTP-u port |
GTP-c port |
|
|---|---|---|
Denied GTPv1 message types |
None |
GTPU_PDU GTPV1_END_MARKER GTPV1_MSG_ERR_IND GTPV1-ALL-MBMS message-types GTPV1-ALL-Location management message-types |
Denied GTPv2 message types |
N/A |
GTP_PKT_ERROR_INDICATION GTP_PKT_DNLK_DATA_FAIL_INDICATION GTP_PKT_STOP_PAGING_INDICATION GTP_PKT_CRE_INDR_TNL_REQ GTP_PKT_CRE_INDR_TNL_RSP GTP_PKT_DEL_INDR_TNL_REQ GTP_PKT_DEL_INDR_TNL_RSP GTP_PKT_RELEASE_BEARERS_REQ GTP_PKT_RELEASE_BEARERS_RSP GTP_PKT_DNLK_DATA GTP_PKT_DNLK_DATA_ACK GTP_PKT_MOD_ACCESS_BEARERS_REQ GTP_PKT_MOD_ACCESS_BEARERS_RSP |
Also, AA FW allows the operator to further restrict allowed message types (shown in the following table) by configuring GTP message type filter entries to deny (or allow) the following message types:
|
GTP-u port |
GTP-c port |
|
|---|---|---|
|
Allowed GTPv1 message types |
GTPV1_MSG_ECHO_REQ GTPV1_MSG_ECHO_RESP GTPV1_SUPP_EXT_HDR_NOTIF GTPV1_MSG_ERR_IND GTPV1_END_MARKER GTPU_PDU |
GTPV1_MSG_ECHO_REQ GTPV1_MSG_ECHO_RESP GTPV1_SUPP_EXT_HDR_NOTIF GTPV1_MSG_VER_NOT_SUPP_IND GTPV1_MSG_PDP_CREATE_REQ GTPV1_MSG_PDP_CREATE_RESP GTPV1_MSG_PDP_UPD_REQ GTPV1_MSG_PDP_UPD_RESP GTPV1_MSG_PDP_DEL_REQ GTPV1_MSG_PDP_DEL_RESP GTPV1_MSG_NET_INIT_REQ GTPV1_MSG_NET_INIT_RESP GTPV1_MSG_MSINFO_REQ GTPV1_MSG_MSINFO_RESP |
|
Allowed GTPv2 message types |
N/A |
GTP_PKT_ECHO_REQ GTP_PKT_ECHO_RSP GTP_PKT_VERSION_NOT_SUPPORTED GTP_PKT_CRE_SES_REQ GTP_PKT_CRE_SES_RSP GTP_PKT_MOD_BEARER_REQ GTP_PKT_MOD_BEARER_RSP GTP_PKT_DEL_SES_REQ GTP_PKT_DEL_SES_RSP GTP_PKT_CHG_NOT_REQ GTP_PKT_CHG_NOT_RSP GTP_PKT_MOD_BEARER_CMD GTP_PKT_MOD_BEARER_FAIL_INDICATION GTP_PKT_DEL_BEARER_CMD GTP_PKT_DEL_BEARER_FAIL_INDICATION GTP_PKT_BEARER_RESOURCE_CMD GTP_PKT_BEARER_RESOURCE_FAIL_INDICATION GTP_PKT_SUSPEND_NOTIFICATION GTP_PKT_SUSPEND_ACK GTP_PKT_RESUME_NOTIFICATION GTP_PKT_RESUME_ACK GTP_PKT_CRE_BEARER_REQ GTP_PKT_CRE_BEARER_RSP GTP_PKT_UPD_BEARER_REQ GTP_PKT_UPD_BEARER_RSP GTP_PKT_DEL_BEARER_REQ GTP_PKT_DEL_BEARER_RSP GTP_PKT_TRACE_SESSION_ACTIVATION GTP_PKT_TRACE_SESSION_DEACTIVATION GTP_PKT_UPDATE_PDN_CONNECTION_SET_REQ GTP_PKT_UPDATE_PDN_CONNECTION_SET_RSP GTP_PKT_DELETE_PDN_CONNECTION_SET_REQ GTP_PKT_DELETE_PDN_CONNECTION_SET_RSP |
By default, the GTP message filter allows all GTP messages.
To configure GTPv2 message filtering, the following command is used:
*A:Dut-C>config>app-assure>group>
+---gtp-filter <gtp-filter-name> [create]
+---gtpc-inspection
| +---message-type-v2
| | |
| | +---default-action {permit|deny}
| | |
| | +---entry <entry-id> value <gtpv2-message-value> action {permit|deny}
| | | no entry <entry-id>
To configure GTPv1 message filtering, the following command is used:
*A:Dut-C>config>app-assure>group>
| +---message-type
| | |
| | +---default-action {permit|deny}
| | |
| | +---entry <entry-id:1..255> value <gtpv1-message-value> action {permit|deny}
| | | no entry <entry-id>
If the operator configures a message type that is invalid for the roaming interface to be denied, it will be dropped and counted under that filter entry (and not tagged as dropped due to "wrong-interface" in the event log). However, configuring the message-type filter to "permit" a message type that is invalid for the roaming interface will not take effect, because the packet with the specified message type will be dropped by the GTP-c protocol inspection process.
Unauthorized APN attack – APN filtering
APN filtering checks GTP-c messages to determine if a roaming subscriber is allowed to access a specified external network (/aka APN). The "create-session-request" and "create pdp request" GTP message types contain an APN IE in the header of a GTP packet. An APN IE consists of an external network ID (for example, nokia.com) and, optionally, a unique ID that identifies the operator PLMN.
APN filtering prevents malicious UEs from initiating a "create PDP/session request" flood attack toward the PGW/GGSN for invalid or disallowed APNs. The operator can configure an AA GTP filter to perform APN filtering to restrict roaming subscribers access to specific external networks.
An APN filter, an IMSI prefix, and an SGSN address pool can be used together to filter GTP packets, as follows:
*A:Dut-C>config>app-assure>group>
+---gtp-filter <gtp-filter-name> [create]
| +---imsi-apn-filter //NEW and all its children attributes
| | +---default-action {permit|deny} //default permit
| | +---entry <entry-id: 1031..2030> create
| | | + apn <string 0|1..32 characters>
| | | |---no apn
| | | + src-gsn ip-prefix-list <ip-prefix-list>
| | | + src-gsn <ip address prefix>
| | | |---no src-gsn
| | | + action {permit|deny} //default permit
| | +---no entry <entry-id>
By default, AA FW permits all APNs.
Unauthorized PLMN access – IMSI prefix filtering
The PLMN of a subscriber home network is identified by combining the Mobile Country Code (MCC) and Mobile Network Code (MNC). MCC-MNC is also known as the International Mobile Station Identity (IMSI) prefix. The IMSI prefix acts as a PLMN identifier.
GTP IMSI prefix filters can be configured to deny GTP incoming traffic from invalid roaming partners. Conversely, GTP IMSI prefix filters can allow only incoming traffic from those network operators that have signed roaming agreements. Any GTP packets with IMSI prefixes not matching the configured prefixes are dropped.
As shown in the Unauthorized APN attack – APN filtering section, IMSI filter entry can also be optionally combined with an SGSN/SGW IP address (or IP address prefix list) to further restrict allowed IMSI prefix traffic to specific SGSN/SGW nodes.
Unauthorized network access
An attacker, using an unauthorized GSN, can cause a DoS attack using spoofed PDP context delete messages (DoS attack) or spoofed update PDP context requests to hijack existing sessions. Such attacks can also spoof a create PDP context request to gain unlawful Internet access. Session hijacking can come from either the SGW/SGSN or the PGW/GGSN. An unauthorized GSN can hijack GTP tunnels or cause a DoS attack by intercepting another GSN and redirecting traffic to it.
Operators can use AA FW to configure pools of trusted GSN IP addresses (using AA IP-prefix-list) to stop spoofed requests from untrusted GSNs. AA IP prefix lists can be configured to model GSN groups, as follows:
*A:Dut-C>config>app-assure>group#
ip-prefix-list ip-prefix-list-name [create]
prefix ip-prefix/ip-prefix-length [name prefix-name]
These lists are then referenced in session filters, such that only sessions that match the lists can be "permitted", as follows:
*A:Dut-C>config>app-assure>group# session-filter
default-action deny
entry # Configure an entry in the session filter
match
src-ip # Configure IPs that correspond to authorized SGW/SSGN
action
permit
Configuration
AA GTP filtering functionality is enhanced in SR OS Release 20.2.R2 to include support for the AA FW feature related to the GTP roaming interface. The GTP filters are optional Application QoS Policy actions (AQP actions). AQPs have partition-level scope, which allows different FW policies to be implemented by using AA partition concepts within the same AA-ISA.
The configuration topology in Configuration topology shows how the VSR equipped with AA FW functionality provides protection for the S8 interfaces.
Pre-setup requirements
Configuration of a VSR router is required if a 7750 SR is not already used in the access network on the S8 interfaces. If a 7750 SR is already deployed, AA-ISA must be configured.
See the Application Assurance — Stateful Firewall chapter for basic knowledge about AA-FW functionality.
Platform-dependent configuration
VSR
For GTP FW deployment in VSR, the following configuration supports load balancing of traffic across multiple CPU cores:
*A:7750-1>config> config>isa>aa-grp# vm-traffic-distribution-by-teid
7750 hardware
GTP FW deployment in 7750 hardware is only supported by ISA2:
*A:7750-1>config> config>isa>aa-grp# minimum-isa-generation 2
Allocation of memory for stateful GTP processing
To support stateful GTP processing (for example, TEID, sequence number, and UE IP validation FW operations), the operator must configure the system to allocate sufficient memory resources, as follows:
*A:7750-1>config>isa>aa-grp# shared-resources
gtp-tunnel-database 100
Configuration to divert SAPs/VPRN traffic into AA-ISA
In this configuration example, one VPRN is used per wireless roaming partner network. In the example, two roaming partner networks are used for illustration. In real networks, this number is much bigger.
However, before configuring SAPs for diversion, the operator can optionally define some Application Service Option (ASO) characteristics to provide different FW policies for different roaming partners, as follows:
*A:7750-1>config>app-assure>group 1:1 policy
begin
app-service-options
characteristic "FW-Protection" persist-id 1 create
value "OFF" persist-id 1
value "ON" persist-id 2
default-value "OFF"
exit
characteristic "strict-FW-Protection" persist-id 2 create
value "OFF" persist-id 1
value "ON" persist-id 2
default-value "OFF"
exit
exit
commit
For more information about ASO configuration, see the Application Assurance — App-Profile, ASO and Control Policies chapter.
After configuring any ASO characteristics, define an application profile and transit IP policy; for example:
*A:7750-1>config>app-assure>group$ info
----------------------------------------------
policy
begin
app-profile "default" create
description "App profile that applies to the whole SAP"
divert
characteristic "FW-Protection" value "ON"
exit
app-profile "strict-FW" create
description "App profile that applies strict FW rules to the SAP"
divert
characteristic "FW-Protection" value "ON"
characteristic "strict-FW-Protection" value "ON"
exit
commit
exit
transit-ip-policy 1 create
def-app-profile "strict-FW"
detect-seen-ip
transit-auto-create
no shutdown
exit
exit
Traffic of these two VPRNs needs to be diverted into AA-ISA to provide firewall protection. Apply the following policies to the SAPs of the two VPRNs:
*A:7750-1>config#
service
customer 1 name "1" create
description "Default customer"
exit
customer 2 name "2" create
exit
vprn 100 name "100" customer 2 create
interface "to-NetA" create
exit
exit
vprn 200 name "200" customer 1 create
interface "to-site1" create
exit
exit
vprn 100 name "100" customer 2 create
description "L3 Service roaming partner 2"
route-distinguisher 100:2
interface "to-NetA" create
address 192.168.1.1/24
sap 1/2/3 create
app-profile "default"
exit
exit
exit
vprn 200 name "200" customer 1 create
description "L3 Service roaming partner 1"
route-distinguisher 200:1
interface "to-site1" create
address 192.168.2.1/24
static-arp 1.1.1.2 00:ff:02:00:00:01
sap 1/2/1 create
transit-policy ip 1
app-profile "strict-FW"
exit
exit
exit
exit
This configuration achieves the following.
Roaming traffic is diverted to AA-ISA for FW protection.
Customer 1 traffic will have a "strict" FW rule attribute, while customer 2 traffic will be subject to basic FW rules.
Within AA-ISA, the customer 1 diverted SAP is treated as a parent SAP.
Instead of treating the whole SAP as a single subscriber, subscribers are auto-created within this SAP, based on the IP address of the SGWs/SSGNs.
If the operator does not require per SGW/SSGN control (such as limiting the total bandwidth of a SGW to prevent DoS attack), the "transit IP policy" from the SAP configuration can be removed. This will cause AA to treat the whole SAP as a single subscriber, as in the case of the customer 2 SAP.
Configuration FW events log
To configure a log that captures events related to various AA firewall actions:
*A:7750-1# configure application-assurance group 1:1
*A:7750-1>config>app-assure>group# event-log "FW_events_log" create
*A:7750-1>config>app-assure>group>evt-log$ buffer-type circular
*A:7750-1>config>app-assure>group>evt-log$ max-entries 100000
*A:7750-1>config>app-assure>group>evt-log$ no shutdown
*A:7750-1>config>app-assure>group>evt-log$ exit
*A:7750-1>config>app-assure>group# info
----------------------------------------------
---snip---
event-log "FW_events_log" create
buffer-type circular
max-entries 100000
no shutdown
exit
Alternatively, due to the limited size of the log and the large amount of traffic AA can handle, it is recommended that the operator use the syslog mechanism instead of local logging, as follows:
config>app-assure>group>event-log>syslog
The event log can be referenced in various FW actions that are configured later in this chapter.
*A:7750-1# tools dump application-assurance group 1:1 event-log "FW_event_log"
isa 1/1
=====================================================
Application-Assurance event-log "FW_events_log"
Current Time: "05/19/2020 19:03:58" (UTC)
group[:partition]: 1:1
isa: 1/1
admin state: no shutdown
buffer-type: circular
max-entries: 100000
=====================================================
Event-source
Action SubType SubName Direction Src-ip
Dst-ip Ip-protocol Src-port Dst-port Timestamp
"gtp filter gtp-filter-partner1 reason: filtered-gtp-message-type, teid: 0x0001d100,
MT: 36, version: 2" deny transit "1_10.10.68.1/32" from-sub 10.10.68.1
10.10.68.3 udp 2123 2123 "05/19/2020 18:54:50"
"gtp filter gtp-filter-partner1 reason: filtered-gtp-message-type, teid: 0x00019100,
MT: 37, version: 2" deny transit "1_10.10.68.1/32" to-sub 10.10.68.3
10.10.68.1 udp 2123 2123 "05/19/2020 18:54:55"
Total Records: 2
=====================================================
The following command clears all the entries within the specified log:
*A:7750-1# clear application-assurance group 1:1 event-log "FW_events_log"
Configuration to limit total traffic from SGWs
Nokia recommends that a total limit be placed on how much bandwidth and how many flows an SGW/SGSN can generate toward the network. The exact limit values are a function of the number of end devices that are served by the roaming partner SGW/SGSN and capacity limits of the HPLMN PGW/GGSN, plus some additional margin.
In the following example, it is assumed that traffic from each roaming SGW will not exceed 1200 concurrent flows/second (serving about 200 roaming UEs) and 50 Mb/s. These need to be replaced in actual deployments with appropriate values that reflect the specific network deployment.
*A:7750-1>config>app-assure>group# info
----------------------------------------------
policer "limit_roamingSGW_Flows" type flow-count-limit
granularity subscriber create
flow-count 1200
gtp-traffic
exit
policer "limit_roamingSGW_bw" type single-bucket-bandwidth
granularity subscriber create
rate 50000
mbs 500
exit
----------------------------------------------
Apply the configured policers as actions from within the default subs-policy AQP entry:
*A:7750-1>config>app-assure>group>policy>aqp#
entry 500 create
description "limit per SGW flow and b/w- partner 1"
match
traffic-direction subscriber-to-network
characteristic "strict-FW-Protection" eq "ON"
exit
action
bandwidth-policer "limit_roamingSGW_bw"
flow-count-limit "limit_roamingSGW_Flows"
exit
no shutdown
exit
For GTP traffic flow count policing, it is important that "aqp-initial-lockup" is enabled:
*A:7750-1# configure application-assurance group 1:1 aqp-initial-lookup
All the preceding actions apply to the traffic direction "subscriber-to-network". These actions do not apply to traffic in the other direction (downlink), because the purpose of the AA FW is to protect the network resources from upstream traffic from compromised roaming partner SGWs.
No policers are placed for the traffic of customer 2, because its profile does not have "strict policing" enabled. A policer can be configured to limit the total bandwidth and flows from all SGWs served to the customer 1 SAP, as follows:
*A:7750-1>config>app-assure>group# info
----------------------------------------------
policer "limit_roamingSGWs_total_Flows" type flow-count-limit
granularity subscriber create
flow-count 12000
gtp-traffic
exit
policer "limit_roamingSGWs_total_bw" type single-bucket-bandwidth
granularity subscriber create
rate 500000
mbs 5000
exit
----------------------------------------------
Apply the configured policers as actions from within the default subs-policy AQP entry, as follows:
*A:7750-1>config>app-assure>group>policy>aqp#
entry 501 create
no shutdown
description "limit total SGW flow and b/w- partner 2 "
match
traffic-direction subscriber-to-network
characteristic "strict-FW-Protection" eq "OFF"
exit
action
bandwidth-policer "limit_roamingSGWs_total_bw"
flow-count-limit "limit_roamingSGWs_total_Flows"
exit
exit
GTP filtering – disallow traffic from unauthorized SGWs
To use GTP filtering to disallow traffic from unauthorized SGWs, perform the following steps:
Create AA IP lists
Use AA IP lists in session filters and AQPs
Reference session filters within AQPs
Create AA IP lists, by creating an AA IP prefix list that contains SGW IP addresses or range of addresses for each customer, as follows:
Roaming partner 1
*A:7750-1>config>app-assure# group 1:1 ip-prefix-list "Roaming1_ALL_SGWs" create description "SGWs subnet-partner 1" prefix 172.16.100.0/24 exit ip-prefix-list "Roaming2_ALL_SGWs" create description "SGWs subnet for roaming partner2" prefix 172.16.110.100/30 exitRoaming partner 2
*A:7750-1>config>app-assure>group# ip-prefix-list "Roaming2_ALL_SGWs" create description "SGWs subnet for roaming partner2" prefix 172.16.110.100/30 exitThe AA IP prefix lists can be referenced and used in AA FW rules using session filters and AQPs, as follows:
*A:7750-1>config>app-assure>group# session-filter "restricted_access_partner1" create description "SGWs_allowed_partner1" default-action deny entry 10 create description "allow GTP-u from authorized subnets" match ip-protocol-num udp src-ip ip-prefix-list "Roaming1_ALL_SGWs" dst-port eq 2152 exit action permit exit entry 11 create description "allow GTP-c from authorized subnets" match ip-protocol-num udp src-ip ip-prefix-list "Roaming1_ALL_SGWs" dst-port eq 2123 exit action permit exit entry 20 create description "allow DNS" match ip-protocol-num * src-ip ip-prefix-list "Roaming1_ALL_SGWs" dst-port eq 53 exit action permit exit exit session-filter "restricted_access_partner2" create description "SGWs_allowed_partner2" default-action deny event-log "FW_events_log" entry 10 create description "allow GTP-u from authorized subnets" match ip-protocol-num udp src-ip ip-prefix-list "Roaming2_ALL_SGWs" dst-port eq 2152 exit action permit exit entry 11 create description "allow GTP-c from authorized subnets" match ip-protocol-num udp src-ip ip-prefix-list "Roaming2_ALL_SGWs" dst-port eq 2123 exit action permit exit entry 20 create description "allow DNS" match ip-protocol-num * src-ip ip-prefix-list "Roaming2_ALL_SGWs" dst-port eq 53 exit action permit exit exitNote:Optionally, you can combine the session filter entries for the two roaming partners into a single session filter (for scale reasons). AA supports a total of 300 session filters. If there are less than 300 roaming partners, you can use a session filter per partner for customization purposes (related to, for example, IP subnets). If the number of partners is greater than the maximum number of session filters, you need to aggregate entries into a fewer number of session filters. Be aware of overlapping IP addresses from different roaming partner networks/VPRNs.
The configured session filters need to be referenced within AQPs, as follows:
*A:7750-1>config>app-assure>group>policy>aqp# entry 510 create description "apply FW rules for roaming partner 1" match traffic-direction subscriber-to-network characteristic "strict-FW-Protection" eq "ON" exit action session-filter "restricted_access_partner1" exit no shutdown exit entry 511 create description "apply FW rules for roaming partner 2" match traffic-direction subscriber-to-network characteristic "strict-FW-Protection" eq "OFF" exit action session-filter "restricted_access_partner2" exit no shutdown exit
Restrict downstream traffic (optional)
Operators can optionally restrict downstream traffic to specific destinations and protocols, as follows:
*A:7750-1>config>app-assure>group#
session-filter "restricted_downstream_traffic_1" create
description "allow only traffic to only signed up partners"
default-action deny
entry 10 create
description "allow GTP-u from authorized subnets"
match
ip-protocol-num udp
dst-ip ip-prefix-list "Roaming1_ALL_SGWs"
dst-port eq 2152
exit
action permit
exit
entry 11 create
description "allow GTP-c to authorized subnets"
match
ip-protocol-num udp
dst-ip ip-prefix-list "Roaming1_ALL_SGWs"
dst-port eq 2123
exit
action permit
exit
entry 20 create
description "allow DNS"
match
ip-protocol-num *
dst-ip ip-prefix-list "Roaming1_ALL_SGWs"
exit
action permit
exit
exit
session-filter "restricted_downstream_partner2" create
description "SGWs_allowed_partner2"
default-action deny event-log "FW_events_log"
entry 10 create
description "allow GTP-u to authorized subnets"
match
ip-protocol-num udp
dst-ip ip-prefix-list "Roaming2_ALL_SGWs"
dst-port eq 2152
exit
action permit
exit
entry 11 create
description "allow GTP-c to authorized subnets"
match
ip-protocol-num udp
dst_ip ip-prefix-list "Roaming2_ALL_SGWs"
dst-port eq 2123
exit
action permit
exit
exit
The preceding configuration provides the most flexibility and allows IP addresses to overlap between different partner networks. However, it comes at the cost of creating separate session filters for each partner. If IP addresses do not overlap, a single session filter is sufficient.
The session filters need to be referenced from AQP, as follows:
*A:7750-1>config>app-assure>group>policy>aqp#
entry 514 create
description "apply FW rules for roaming partner 1"
match
traffic-direction network-to-subscriber
characteristic "strict-FW-Protection" eq "ON"
exit
action
session-filter "restricted_downstream_partner1"
exit
no shutdown
exit
entry 513 create
description "apply FW rules for roaming partner 2"
match
traffic-direction network-to-subscriber
characteristic "strict-FW-Protection" eq "OFF"
exit
action
session-filter "restricted_downstream_partner2"
exit
no shutdown
exit
Configuration to protect against malformed packets
It is always recommended in FW deployments that overload-drop, error-drop, and fragment-drop are enabled within the default sub-policy, as follows:
*A:7750-1>config>app-assure>group>policy>aqp#
entry 50 create
description "drop error and fragmented packets"
action
overload-drop event-log "FW_events_log"
error-drop event-log "FW_events_log"
fragment-drop all event-log "FW_events_log"
exit
no shutdown
exit
The overload-drop action ensures that AA-ISA, if it gets overloaded, drops the excess traffic instead of cutting it through without applying FW rules.
The error-drop action ensures that AA-ISA drops malformed IP packets.
The fragment-drop all action allows the operator to drop all fragmented traffic, drop out-of-order fragments only, or allow fragments through. Because many network DoS attacks use IP fragmentation to initiate attacks, allowing fragments through is not recommended for firewall deployments. As a minimum, if fragmentation is used, the operator is recommended to configure AA to drop out-of-order fragmented packets.
The preceding actions are applied to all traffic. Therefore, there are no AQP match conditions configured.
Plausibility of GTP messages and GTP message validation
To protect the network from malformed GTP packets and associated attacks as described in the overview section, a GTP filter needs to be created and referenced from an AQP entry.
Configure the GTP filter object to:
Enable GTP-c inspection so that the FW:
Ensures the correct IE states and order
Discards any GTP packet that contains an invalid message type for S5/S8 (Gn/Gp) interface
Enable sequence number checking for GTP-c traffic (for partner 1 traffic)
Enable the GTP filter to check and drop errored GTP packets (anomalies)
Enable GTP message length checking (to minimize exposure to code injection attacks). The maximum is set here (for example, 1250 bytes). The value is operator dependent, and should be replaced with the figure used by the operator.
Drop GTP-in-GTP encapsulated packets
*A:7750-1>config>app-assure>group>gtp# event-log "FW_events_log" gtpc-inspection gtp-filter "gtp-filter-partner1" create description "gtp-filter for partner 1" max-payload-length 1250 event-log "FW_events_log" action deny gtp-in-gtp deny gtp-tunnel-database validate-sequence-number exit exit gtp-filter "gtp-filter-partner2" create description "gtp-filter for partner 2" max-payload-length 1250 event-log "FW_events_log" action deny gtp-in-gtp deny no shutdownThe configured GTP filters need to be referenced from AQP entries, as follows:
*A:7750-1>config>app-assure>group>policy>aqp# entry 512 create description "apply SGW GTP filter rules" match characteristic "strict-FW-Protection" eq "ON" exit action gtp-filter "gtp-filter-partner1" exit no shutdown exit entry 513 create description "apply SGW GTP filter rules" match characteristic "strict-FW-Protection" eq "OFF" exit action gtp-filter "gtp-filter-partner2" exit no shutdown exit
Filtering of GTP message types
In this configuration, traffic from partner 2 is considered "safe/trusted". Therefore, unlike traffic from partner 1, no additional GTP message-type filtering is applied to it, beyond the GTP Cat-1 (see Allowed GTP message types (Cat-1) ) message filtering applied as a result of enabling GTP-c inspection.
For roaming partner 1 traffic, the GTP filter is configured to block some Cat-1 optional message types (GTPv1 and GTPv2):
GTPv2: Trance session activation/deactivation (this is optional for S8)
GTPv1: Allows only the message types used by GTP-u and blocks GTPv1 message types used by GTP-c
By configuring GTP-c inspection, only Cat-1 message types (see Allowed GTP message types (Cat-1) ) are allowed and all others are denied. Therefore, there is little to no need for additional GTP message filtering configuration.
The GTP filter is configured as follows:
*A:7750-1>config>app-assure>group>gtp#
event-log "FW_events_log" action deny
gtpc-inspection
gtp-filter "gtp-filter-partner1" create
description "gtp-filter for partner 1"
max-payload-length 1250
event-log "FW_events_log" action deny
message-type
default-action deny
entry 1 value "echo-request" action permit
entry 2 value "echo-response" action permit
entry 3 value "error-indication" action permit
entry 4 value "supported-extension-headers-notification"
action permit
entry 5 value "end-marker" action permit
entry 6 value "g-pdu" action permit
exit
message-type-gtpv2
default-action permit
entry 524 value "trace-session-activation" action deny
entry 525 value "trace-session-deactivation" action deny
exit
gtp-in-gtp deny
imsi-apn-filter
default-action deny
entry 1031 create
apn ANY_APN
mcc-mnc-prefix 161379
action permit
exit
exit
gtp-tunnel-database
validate-sequence-number
exit
exit
TEID validation
For roaming partner 1, to protect the network resources from spoofed TEIDs, the FW is recommended to verify that the TEIDs used in the GTP-u traffic are valid (that is, correctly negotiated via GTP-c), as follows:
*A:7750-1>config>app-assure>group>gtp#
gtp-filter "gtp-filter-partner1"
gtp-tunnel-database
validate-gtp-tunnels
exit
exit
Since roaming partner 2 network is trusted, no TEID validation is needed.
UE IP address anti-spoofing
It is a good practice to protect the network against UEs spoofing a different IP address, as follows:
*A:7750-1>config>app-assure>group>gtp#
gtp-filter "gtp-filter-partner1"
gtp-tunnel-database
validate-source-ip-addr
exit
exit
This example applied to partner 1 traffic. Validation of source IP requires the use of a GTP tunnel database.
APN and IMSI filtering
In this example, only Home-Routed (HR) traffic from partner 1 is allowed, regardless of the APN. The rest is denied. This is achieved by configuring an IMSI prefix (="1613797") that corresponds to the Home network.
For roaming partner 2, MVNO traffic is allowed as well as HR traffic. This MVNO traffic (specific IMSI prefix = "1613400" in this example) is only allowed to attach to the mvnoguest.com APN, as follows:
*A:7750-1>config>app-assure>group>gtp#
gtp-filter "gtp-filter-partner1"
imsi-apn-filter
default-action deny
entry 1031 create
apn ANY_APN
mcc-mnc-prefix 161379
action permit
exit
exit
exit
gtp-filter "gtp-filter-partner2"
imsi-apn-filter
default-action deny
entry 1040 create
apn mvnnoguest.com$
mcc-mnc-prefix 161340
action permit
exit
entry 1041 create
apn ANY_APN
mcc-mnc-prefix 161379
action permit
exit
exit
exit
Limiting concurrent session creations
To further lower the risk of DoS attacks using massive amounts of session/PDN create messages, it is recommended that the operator configure the maximum concurrent number of endpoints (TIEDs) that an SGW can create.
In this example, the limit that is configured in the GTP filter corresponds to the maximum concurrent TEIDs that can be created by any SGW IP address, as follows:
*A:7750-1>config>app-assure>group>gtp#
gtp-filter "gtp-filter-partner1"
gtp-tunnel-database
default-tunnel-endpoint-limit 400
exit
Configuring FW statistics
To gain visibility into the traffic passing through the FW and the FW actions taken, it is highly recommended to enable "deny-admit" statistics, as follows:
A:7750-1>config>#
log
file-id 5
location cf3:
exit
accounting-policy 5
description "LogFileforAAFirewallAccounting"
record aa-admit-deny
collection-interval 10
to file 5
no shutdown
exit
exit
A:7750-1>config>app-assure>group#
statistics
aa-admit-deny
accounting-policy 5
collect-stats
gtp-filter-stats
session-filter-stats
policer-stats-resources
policer-stats
exit
protocol
shutdown
exit
Configuring threshold crossing alerts
As well as admit-deny statistics, the operator can optionally enable the FW to generate Threshold Crossing Alerts (TCAs) against the collected statistics.
NSP also supports TCAs. The operator has a choice to enable TCAs on both the FW and/or NSP. The advantage of TCAs generated directly from the FW is that they tend to be more real-time relative to NSP TCAs. However, NSP supports a larger TCA scale than the FW.
The operator needs to set the low- and high-water marks according to the conditions of their networks. The following values are for illustration purposes only.
A:7750-1> config>app-assure>group>stats#
threshold-crossing-alert
gtp-sanity-drop direction from-sub create
high-wmark 100 low-wmark 60
exit
threshold-crossing-alert
gtp-sanity-drop direction from-sub create
high-wmark 100 low-wmark 60
exit
gtp-filter "gtp-filter-partner1"
validate-gtp-tunnels direction from-sub create
high-wmark 100 low-wmark 60
exit
validate-sequence-number direction from-sub create
high-wmark 100 low-wmark 60
exit
validate-src-ip-addr direction from-sub create
high-wmark 100 low-wmark 60
exit
missing-mandatory-ie direction from-sub create
high-wmark 100 low-wmark 60
exit
tunnel-resource-limit direction from-sub create
high-wmark 100 low-wmark 60
exit
tunnel-endpoint-limit direction from-sub create
high-wmark 100 low-wmark 60
exit
message-type
default-action direction from-sub create
high-wmark 100 low-wmark 60
exit
header-sanity direction from-sub create
high-wmark 100 low-wmark 60
exit
exit
message-type-gtpv2
entry 524 direction from-sub create
high-wmark 100 low-wmark 60
exit
entry 525 direction from-sub create
high-wmark 100 low-wmark 60
exit
exit
imsi-apn-filter
default-action direction from-sub create
high-wmark 100 low-wmark 60
exit
exit
exit
gtp-filter "gtp-filter-partner2"
missing-mandatory-ie direction from-sub create
high-wmark 100 low-wmark 60
exit
tunnel-resource-limit direction from-sub create
high-wmark 100 low-wmark 60
exit
tunnel-endpoint-limit direction from-sub create
high-wmark 100 low-wmark 60
exit
imsi-apn-filter
default-action direction from-sub create
high-wmark 100 low-wmark 60
exit
exit
exit
exit
Configuring GTP and GTP-c applications
By configuring AA app-filters to define GTP-u and GTP-c applications, the operator can gain further visibility into the volume of traffic of these applications, as follows:
A:7750-1>config> config>app-assure>group>
policy
begin
application "GTP_c" create
exit
application "GTP_other" create
exit
application "GTP_u" create
exit
app-filter
entry 40000 create
protocol eq "gtp"
server-port eq 2152
application "GTP_u"
no shutdown
exit
entry 40010 create
protocol eq "gtp"
server-port eq 2123
application "GTP_c"
no shutdown
exit
entry 40020 create
protocol eq "gtp"
application "GTP_other"
no shutdown
exit
exit
commit
The export and display of statistics related to these applications use standard AA per application per partition or per application per subscriber XML records and "show" routines.
Relevant debug routines
CLI show routines
*A:7750-1>config>app-assure>group>gtp>gtp-fltr# show application-assurance
group 1:1 session-filter "restricted_access_partner1"
===============================================================================
AA Session Filter Instance "restricted_access_partner1"
===============================================================================
Description : SGWs_allowed_partner1
Default Action : deny
Event Log : (Not Specified)
AQP Entries :
510
-------------------------------------------------------------------------------
Filter Match Criteria
-------------------------------------------------------------------------------
Entry : 10
Description : allow GTP-u from authorized subnets
IP Protocol : udp
Source IP List : Roaming1_ALL_SGWs
Dest Port : eq 2152
Action : permit
Event Log : (Not Specified)
Hits : 1 flows
-------------------------------------------------------------------------------
Entry : 11
Description : allow GTP-c from authorized subnets
IP Protocol : udp
Source IP List : Roaming1_ALL_SGWs
Dest Port : eq 2123
Action : permit
Event Log : (Not Specified)
Hits : 2 flows
-------------------------------------------------------------------------------
Entry : 20
Description : allow DNS
IP Protocol : *
Source IP List : Roaming1_ALL_SGWs
Dest Port : eq 53
Action : permit
Event Log : (Not Specified)
Hits : 0 flows
-------------------------------------------------------------------------------
No. of entries : 3
===============================================================================
*A:7750-1>show application-assurance group 1:1 gtp gtp-filter "gtp-filter-partner1"
===============================================================================
Application Assurance Group 1:1 GTP Filter "gtp-filter-partner1"
===============================================================================
Description : gtp-filter for partner 1
Maximum payload length : 1250
Event log : FW_events_log
Event log action : deny
Default action : deny
Default GTPv2 action : permit
Default IMSI-APN action : deny
GTP in GTP action : deny
Validate GTP tunnels : enabled
Validate sequence number : enabled
Validate source IP address : enabled
GTP tunnel endpoint limit : 400
Configured messages : 6
Configured GTPv2 messages : 2
Configured IMSI-APN filters : 1
Packets arrived : 18
Packets denied
Payload length : 0
Message type : 0
GTPv2 message type : 2
IMSI-APN filter : 0
Mandatory header : 0
Extension header : 0
Information element : 0
Invalid TEID : 0
Invalid sequence number : 0
Invalid source IP address : 0
Missing mandatory IE : 0
GTP in GTP : 0
No tunnel resource : 0
Tunnel endpoint limit : 0
Packets permitted : 16
===============================================================================
*A:7750-1>show application-assurance group 1:1 gtp
===============================================================================
Application Assurance Group 1:1 GTP
===============================================================================
Admin status : Up
Event log : FW_events_log
Event log action : deny
Mode : filtering
GTP-C inspection : Enabled
-------------------------------------------------------------------------------
GTP Statistics sub-to-net net-to-sub
-------------------------------------------------------------------------------
Incoming packets 9 9
Packets denied
UDP packet length 0 0
GTP message length 0 0
GTP version 0 0
-------------------------------------------------------------------------------
Packets permitted 9 9
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
GTP Policing Statistics sub-to-net net-to-sub
-------------------------------------------------------------------------------
Packets arrived 9 9
Packets denied
gtp-traffic flow-count policer 0 0
Other 0 0
-------------------------------------------------------------------------------
Packets permitted 9 9
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
GTP Filter Statistics sub-to-net net-to-sub
-------------------------------------------------------------------------------
Packets arrived 9 9
Packets denied 1 1
Packets permitted
gtp-filter 8 8
no gtp-filter 0 0
-------------------------------------------------------------------------------
Total GTP packets permitted 8 8
===============================================================================
*A:7750-1>show application-assurance group 1 aa-sub-list
==============================================================================
Application-Assurance Subscriber List for Group 1
==============================================================================
type aa-sub ISA App-Profile divert
assigned
------------------------------------------------------------------------------
group 1:1
------------------------------------------------------------------------------
sap 1/2/1 1/1 strict-FW Yes
sap 1/2/3 1/1 default Yes
transit 1_10.10.68.1/32 1/1 strict-FW Yes
------------------------------------------------------------------------------
Number of aa-subs found in group 1:1 : 3
Total number of aa-subs found : 3
==============================================================================
CLI tools dump routines
*A:7750-1>tools dump application-assurance group 1:1 flow-record-search isa 1/1
=====================================================
Application-Assurance flow record search
Search Start Time: "05/19/2020 19:04:37" (UTC)
Search Criteria:
group[:partition]: 1:1
isa: 1/1
protocol name: none specified
application name: none specified
app-group name: none specified
flow-status: none specified
start-flowId: none specified
classified: none specified
server-ip: none specified
server-port: none specified
client-ip: none specified
bytes-tx: none specified
flow-duration: none specified
max-count: none specified
flow-modified: none specified
search-type: default
=====================================================
FlowId Init Src-ip Dst-ip Ip-prot Src-prt Dst-prt
Protocol Application
Pkts-tx Bytes-tx Pkts-disc Bytes-disc
Time-ofp(UTC) Time-olp(UTC)
2 no 10.10.68.3 10.10.68.1 udp 2123 2123
"gtp" "GTP_c"
1 46 0 0
"05/19/2020 18:54:50" "05/19/2020 18:54:50"
3 yes 10.10.68.1 10.10.68.3 udp 2123 2123
"gtp" "GTP_c"
2 359 0 0
"05/19/2020 18:54:50" "05/19/2020 18:54:50"
4 yes 10.10.68.3 10.10.68.1 udp 2123 2123
"gtp" "GTP_c"
2 326 1 51
"05/19/2020 18:54:50" "05/19/2020 18:54:55"
7 yes 10.10.68.1 10.10.68.3 udp 63760 2152
"gtp" "GTP_u"
5 500 0 0
"05/19/2020 18:54:50" "05/19/2020 18:54:50"
8 yes 10.10.68.3 10.10.68.1 udp 64784 2152
"gtp" "GTP_u"
5 500 0 0
"05/19/2020 18:54:50" "05/19/2020 18:54:50"
11 yes 10.10.68.1 10.10.68.3 udp 2123 2123
"gtp" "GTP_c"
1 136 1 91
"05/19/2020 18:54:50" "05/19/2020 18:54:50"
SEARCH COMPLETED.
Search End Time: "05/19/2020 19:04:37" (UTC)
Total Records: 6
=====================================================
*A:7750-1>tools dump application-assurance group 1:1 admit-deny-stats
============================================================================================================================================
Application-Assurance Group 1:1 Admit-Deny Statistics
============================================================================================================================================
--------------------------------------------------------------------------------------------------------------------------------------------
Admitted Sub-To-Net Denied Sub-To-Net Admitted Net-To-Sub Denied Net-To-Sub
Packet Validation Statistics
(Packets) (Packets) (Packets) (Packets)
--------------------------------------------------------------------------------------------------------------------------------------------
Error
0 0 0 0
Fragments: Out-Of-Order
0 0 0 0
Fragments: All
0 0 0 0
Overload
N/A 0 N/A 0
GTP Sanity
9 0 9 0
--------------------------------------------------------------------------------------------------------------------------------------------
Admitted Sub-To-Net Denied Sub-To-Net Admitted Net-To-Sub Denied Net-To-Sub
GTP Filter Statistics
(Packets) (Packets) (Packets) (Packets)
--------------------------------------------------------------------------------------------------------------------------------------------
GTP Filter: gtp-filter-partner1
Entry: 1 echo-request
0 0 0 0
Entry: 2 echo-response
0 0 0 0
Entry: 3 error-indication
0 0 0 0
Entry: 4 supported-extension-headers-notification
0 0 0 0
Entry: 5 end-marker
0 0 0 0
Entry: 6 g-pdu
5 0 5 0
Message Type Default Action
0 0 0 0
GTPv2 Entry: 524 trace-session-activation
0 1 0 0
GTPv2 Entry: 525 trace-session-deactivation
0 0 0 1
GTPv2 Message Type Default Action
3 0 3 0
IMSI-APN Entry: 1031
N/A 0 N/A 0
IMSI-APN Filter Default Action
N/A 0 N/A 0
Max Payload Length
N/A 0 N/A 0
Message Type Header Sanity
N/A 0 N/A 0
Invalid TEID
N/A 0 N/A 0
Invalid Sequence Number
N/A 0 N/A 0
Invalid Source IP Address
N/A 0 N/A 0
Missing Mandatory IEs
N/A 0 N/A 0
GTP in GTP Action
N/A 0 N/A 0
GTP Tunnel DB Resource
N/A 0 N/A 0
Tunnel Endpoint Limit
N/A 0 N/A 0
GTP Filter: gtp-filter-partner2
Message Type Default Action
0 0 0 0
GTPv2 Message Type Default Action
0 0 0 0
IMSI-APN Entry: 1040
N/A 0 N/A 0
IMSI-APN Entry: 1041
N/A 0 N/A 0
IMSI-APN Filter Default Action
N/A 0 N/A 0
Max Payload Length
N/A 0 N/A 0
Message Type Header Sanity
N/A 0 N/A 0
Invalid TEID
N/A 0 N/A 0
Invalid Sequence Number
N/A 0 N/A 0
Invalid Source IP Address
N/A 0 N/A 0
Missing Mandatory IEs
N/A 0 N/A 0
GTP in GTP Action
N/A 0 N/A 0
GTP Tunnel DB Resource
N/A 0 N/A 0
Tunnel Endpoint Limit
N/A 0 N/A 0
--------------------------------------------------------------------------------------------------------------------------------------------
Admitted Sub-To-Net Denied Sub-To-Net Admitted Net-To-Sub Denied Net-To-Sub
Session Filter Statistics
(Sessions) (Packets) (Sessions) (Packets)
--------------------------------------------------------------------------------------------------------------------------------------------
Session Filter: restricted_access_partner1
Entry: 10
1 0 0 0
Entry: 11
2 0 0 0
Entry: 20
0 0 0 0
Default Action
0 0 0 0
Session Filter: restricted_access_partner2
Entry: 10
0 0 0 0
Entry: 11
0 0 0 0
Entry: 20
0 0 0 0
Default Action
0 0 0 0
Session Filter: restricted_downstream_partner1
Entry: 10
0 0 1 0
Entry: 11
0 0 1 0
Entry: 20
0 0 0 0
Default Action
0 0 0 0
Session Filter: restricted_downstream_partner2
Entry: 10
0 0 0 0
Entry: 11
0 0 0 0
Default Action
0 0 0 0
--------------------------------------------------------------------------------------------------------------------------------------------
Admitted Sub-To-Net Denied Sub-To-Net Admitted Net-To-Sub Denied Net-To-Sub
Flow Policer Statistics
(Flows) (Flows) (Flows) (Flows)
--------------------------------------------------------------------------------------------------------------------------------------------
Subscriber Flow Count Policers
limit_roamingSGW_Flows
0 0 0 0
limit_roamingSGWs_total_Flows
0 0 0 0
--------------------------------------------------------------------------------------------------------------------------------------------
Conclusion
A 3GPP roaming interface using GTP presents a security risk to mobile access networks. The AA GTP stateful firewall protects the network infrastructure from untrusted roaming partner networks.