Application Assurance — Security Gateway Stateful Firewall
This chapter provides information about Application Assurance Security gateway stateful firewall.
Topics in this chapter include:
Applicability
This chapter is applicable to all chassis supporting Application Assurance (AA).
The chapter was initially written based on SR OS Release 13.0.R2, but the CLI in the current edition is based on SR OS Release 25.3.R2.
Overview
The SR OS AA stateful firewall feature runs on AA-ISA and extends application-level analysis to provide an in-line stateful service, integrated within the Security Gateway (SeGW). The feature provides protection for mobile infrastructure: Mobility Management Entities (MMEs), Serving Gateways (SGWs), and Network Management Systems (NMSs), against attacks from compromised base stations, evolved NodeBs (eNBs), or Femto Access Points (FAPs). AA stateful packet filtering, combined with AA layer 7 classification and control, provides advanced, next-generation firewall functionality. Using stateful packet filtering, the AA FW not only inspects packets at layers 3 to 7, but also monitors the connection state.
AA FW deployed within a SeGW in ultra-broadband access networks (3G, 4G, or Femto) provides back-end core network security protection, as per LTE SeGW firewall deployment. AA FW offers protection for the following 3rd Generation Partnership Project (3GPP) defined interfaces:
-
S1-MME
-
S1-U
-
Operations, Administration, and Maintenance (OAM)
Similarly, the SeGW architecture for Femto deployment is based on two SR OS systems terminating the mobile backhaul side (front-end and connecting to, for example, a base station router gateway and other network elements of the packet core (back-end), as per SeGW in small cells architecture:
The two SeGWs run in stateful redundant mode: upon partial or total failure of the active SeGW for a set of IPSec tunnels, the other SeGW takes over without terminating the IPSec tunnels, providing hitless failover.
In addition to MS-ISA hardware dedicated to the IPSec function, each SeGW supports one or more additional MS-ISAs running AA to provide firewall capabilities. The firewall rules protect the BSR as well as the BSR-GW and packet core network elements (NEs) from malicious attacks or unauthorized traffic.
The objective of this chapter is to describe the required configuration within AA-ISA to enable AA FW and protection for S1-MME, S1-U, and OAM traffic. Basic knowledge of AA-ISA diversion configuration is assumed.
S1-MME traffic protection
The purpose of AA FW in this deployment is to protect the MME infrastructure against an attack from a compromised eNB or FAP. Network flooding attacks, malformed packets, and port scans are examples of denial of service (DoS) attacks that can be carried out using a compromised eNB or FAP.
AA FW provides inspection of the Stream Control Transmission Protocol (SCTP) used to communicate to the MME. Such inspection includes checking for SCTP payload protocol IDs (PPIDs), source and destination ports, SCTP chunk validation, and malformed SCTP packets, such as checksum validation. In addition, the operator can configure DoS flooding rules, such as policers to limit the bandwidth and flow counts of SCTP traffic.
S1-U traffic protection
The purpose of AA FW in this deployment is to protect the SGW infrastructure against an attack from a compromised eNB or FAP. AA FW supports protection against:
malformed GPRS Tunneling Protocol User plane (GTP-U) packet attacks
Checking packet sanity, which include GTP-U mandatory, optional, and extension header checks, as well as checks for invalid reserved information elements (IE) and missing IEs.
unsupported GTP messages
Filtering messages based on message type and message length.
flooding attacks
Shaping GTP traffic bandwidth, which limits the GTP-U bandwidth that a FAP can send to the core (SGW).
Limiting GTP tunnels, which limits the number of concurrent GTP tunnels and setup rate of these tunnels from a FAP to the core network.
To prevent the shared resources of bandwidth and the SGW processor from being consumed by an attacker, Nokia recommends the GTP flow rate limiting configuration.
IP fragmentation-based attacks
Applying various drop rules for IP fragmentation of GTP messages.
OAM traffic protection
The purpose of AA FW protection in this deployment is to protect against any abuse of OAM network resources, such as NMS.
Network flooding attacks, malformed packets, and port scans are examples of such attacks that can be carried out using a compromised eNB or FAP.
See the configuration described in the Application Assurance — Stateful Firewall chapter for this context of OAM protection in SeGW.
Configuration
AA-ISA Application QoS Policies (AQPs) can contain AQP actions that provide SCTP and GTP filtering functionality. As with all AQPs, these actions 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 the SeGW FW functionality of S1-U and S1-MME interfaces. Geo-redundancy, which is a very common deployment option, is not described in this chapter because it is described in the Multi-Chassis IPSec Redundancy chapter.
Initial setup with multi-chassis IPSec redundancy
Tunnel ISAs are configured with optional multi-chassis redundancy. See the Multi-Chassis IPSec Redundancy chapter for more information.
1 Divert AA traffic and apply basic firewall rules
In this section, the following steps are described:
1.1 Divert private VPRN traffic into AA-ISA with AA multi-chassis redundancy
This step is required for any of the configurations in steps 2, 3, or 4. There is no dependency between steps 2, 3, or 4.
In this example, one private VPRN is used for all traffic to and from eNBs. In some small cell deployments, eNB traffic is split into three different VPRNs: one for control (S1-MME), one for management (OAM), and one for bearer traffic (S1-U GTP-U). In that case, each of these VPRNs needs to be diverted into AA-ISA to provide firewall protection.
First, define an application profile and transit IP policy, such as:
configure
application-assurance
group 1:1 create
policy
begin
app-profile "default" create
description " App profile that applies to the whole SAP"
divert
exit
commit
exit
transit-ip-policy 1 create
description "Per eNB-IP Sub policy"
detect-seen-ip
transit-auto-create
no shutdown
exit
Then, apply the application profile and the transit IP policy to the SAP on the private side of the IPSec tunnel ISA:
configure
service
vprn "VPRN-2"
interface "int-IPsec-Private-1" tunnel create
sap tunnel-1.private:1 create
transit-policy ip 1
app-profile "default"
This configuration achieves:
-
Traffic to or from the IPSec tunnel ISA private SAP is diverted to AA-ISA for the purpose of FW protection
-
Within AA-ISA, the diverted SAP is treated as a parent SAP. That is, instead of treating the whole SAP as a single subscriber, subscribers are auto-created within this SAP based on the IP address of the eNBs
1.2 Protect against malformed packets
In firewall deployments, it is recommended that overload-drop, error-drop, and fragment-drop [all] are enabled within the default sub-policy, as shown in the following example:
-
overload-drop ensures that AA-ISA, when overloaded, drops the excess traffic instead of allowing it through, without applying firewall rules.
-
error-drop ensures that AA-ISA drops malformed IP packets.
-
fragment-drop: because many network DoS attacks use IP fragmentation to initiate attacks, the operator has the option to drop all fragmented traffic, drop out-of-order fragments only, or allow fragments through. Allowing fragments through is not recommended for firewall deployments.
configure application-assurance group 1:1 create policy begin app-qos-policy entry 500 create description "apply SeGW session filter rules" match traffic-direction subscriber-to-network exit action overload-drop error-drop fragment-drop all exit no shutdown exit exit commit
1.3 Limit total traffic from any eNB
Nokia recommends that a total limit be placed on how much bandwidth and how many flows an eNB or FAP can generate toward the network, regardless of the type of traffic.
The limit values are a function of the number of end devices that are served by the eNB or FAP, plus some additional margin:
configure
application-assurance
group 1
policer "limit_eNBs_total_Flows" type flow-count-limit
granularity subscriber create
flow-count 1000
exit
policer "limit_eNBs_total_bw" type single-bucket-bandwidth
granularity subscriber create
rate 500
mbs 500
exit
If the traffic from eNB or FAP is separated into different private SAPs, based on traffic type (S1-AP, S1-U, or OAM), as with some deployment topologies, then the policing limit value is dependent on the SAP traffic type as well as the number of end devices. See policing limit settings in steps 2 and 3.
Apply the configured policers as actions from within the default sub-policy AQP entry:
configure
application-assurance
group 1:1 create
policy
begin
app-qos-policy
entry 500 create
description "apply SeGW session filter rules"
match
traffic-direction subscriber-to-network
exit
action
bandwidth-policer "limit_eNBs_total_bw"
flow-count-limit "limit_eNBs_total_Flows"
overload-drop
error-drop
fragment-drop all
exit
no shutdown
exit
exit
commit
All of the preceding listed actions use the traffic direction of subscriber-to-network. That is, they are not applied to traffic in the other direction (downstream) because the purpose of the firewall is to protect the network resources from upstream traffic coming from compromised eNBs or FAPs.
2 Configure AA-ISA to provide firewall protection to protect MMEs (S1-AP traffic)
The following steps are described in this section:
2.1 Create IP AA lists
First, create an AA IP prefix list that contains eNB IP addresses or range of addresses:
configure
application-assurance
group 1:1 create
ip-prefix-list "ALL_eNBs" create
description "eNodeB subnet"
prefix 172.16.100.0/24
exit
Optionally, create an AA IP list that contains MME IP addresses (in case there are more than one):
configure
application-assurance
group 1:1 create
ip-prefix-list "MMEs" create
description "MMEs subnet"
prefix 172.16.110.100/30
exit
After the preceding lists are created, they can be referenced and used in AA FW rules using session filters and AQPs.
2.2 Allow only SCTP traffic toward MMEs — no port scanning
A basic setup creates session-filter rules that only allow SCTP traffic between eNBs and MMEs.
configure
application-assurance
group 1:1 create
session-filter "SeGW_FW" create
default-action deny
entry 1 create
description "allow SCTP to MMEs"
match
ip-protocol-num "sctp"
src-ip ip-prefix-list "ALL_eNBs"
dst-ip ip-prefix-list "MMEs"
dst-port eq 6005
exit
action permit
exit
In the preceding configuration, SCTP traffic on MMEs is assumed to be running on port 6005.
The newly created session filter needs to be referenced from a default sub-policy AQP action, as follows:
configure
application-assurance
group 1:1 create
policy
begin
app-qos-policy
entry 500 create
description "apply SeGW session filter rules"
match
traffic-direction subscriber-to-network
exit
action
bandwidth-policer "limit_eNBs_total_bw"
flow-count-limit "limit_eNBs_total_Flows"
session-filter "SeGW_FW"
overload-drop
error-drop
fragment-drop all
exit
no shutdown
exit
Using traffic direction subscriber-to-network in the preceding AQP entry achieves two objectives:
-
Protecting MMEs by allowing only SCTP traffic to be initiated from eNB subnets toward MMEs. Port scanning toward MME is blocked.
-
Allowing MMEs to have full access to eNBs.
It is important that an AQP, containing a session filter action, does not contain any matching condition other than ASOs, traffic direction, or subscriber ID. Subscriber ID is not applicable in this deployment use case.
2.3 DoS protection — limit the number of SCTP flows from eNBs
In this step, the operator configures a flow count policer to limit the number of SCTP flows that an eNB can generate toward the MMEs. This protects the MMEs against a compromised eNB trying to set up many SCTP flows.
configure
application-assurance
group 1 create
policer "sctp_flow_count" type flow-count-limit granularity subscriber create
flow-count 2
exit
In the preceding configuration, an eNB or FAP can have up to two flows at a time. In practice, there should only be one SCTP session, one flow in each direction, per eNB-MME pair. The preceding example uses two flows to leave a margin in case a second, backup, MME needs to communicate with the eNB, while still providing enough protection.
Add the defined policer as a flow-count-limit AQP action, as follows:
configure
application-assurance
group 1:1 create
policy
begin
app-qos-policy
entry 100 create
description "limit SCTP traffic"
match
traffic-direction subscriber-to-network
ip-protocol-num eq sctp
exit
action
flow-count-limit "sctp_flow_count"
exit
no shutdown
exit
Configure an AA FW events log
It is sometimes advisable to configure a log that captures events related to various AA FW actions. Because of the limited size of the log and the large amount of traffic AA can handle, consider the usefulness of the information in the log when:
-
debugging a configuration
-
testing a configuration in a staged environment
-
capturing infrequent actions
The following configures a log called "FW_drops_log":
configure
application-assurance
group 1:1 create
event-log "FW_drops_log" create
buffer-type circular
max-entries 100000
no shutdown
exit
The following adds the configured log to the default-action of the session filter:
configure
application-assurance
group 1:1 create
session-filter "SeGW_FW" create
default-action deny event-log "FW_drops_log"
entry 1 create
description "allow SCTP to MMEs"
match
ip-protocol-num "sctp"
src-ip ip-prefix-list "ALL_eNBs"
dst-ip ip-prefix-list "MMEs"
dst-port eq 6005
exit
action permit
exit
The following tools command shows the log:
*A:SeGW-2# tools dump application-assurance group 1:1 event-log "FW_drops_log" isa 1/2
=====================================================
Application-Assurance event-log "FW_drops_log"
Current Time: "06/11/2025 09:44:36" (UTC)
group[:partition]: 1:1
isa: 1/2
admin state: no shutdown
buffer-type: circular
max-entries: 100000
=====================================================
Event-source Action SubType SubName Direction Src-ip
Total Records: 0
=====================================================
The following command clears all the entries within the specified log:
clear application-assurance group 1:1 event-log "FW_drops_log"2.4 DoS protection — limit the SCTP bandwidth from eNB
Similar to the previous step, the operator configures a flow bandwidth policer to limit the amount of SCTP traffic that an eNB can generate toward the MMEs. This protects the MMEs against a compromised eNB trying to flood the MMEs.
configure
application-assurance
group 1 create
policer "sctp_bw_limit" type single-bucket-bandwidth
granularity subscriber create
rate 30
mbs 10
exit
In the preceding example, a single leaky-bucket policer is configured with a rate set to 30 kb/s and maximum burst size of 10 kbytes. This provides enough bandwidth to ensure normal operations, while still providing a ceiling limit of how much traffic any eNB can send toward the MMEs.
-
Uplink — toward MME : 2.7 kb/s
-
Downlink — from MME toward FAP : 28 kb/s
The following command adds the defined policer as a subscriber policy:
configure
application-assurance
group 1:1 create
policy
begin
app-qos-policy
entry 100 create
description "limit SCTP traffic"
match
traffic-direction subscriber-to-network
ip-protocol-num eq sctp
exit
action
bandwidth-policer "sctp_bw_limit"
flow-count-limit "sctp_flow_count"
exit
no shutdown
exit
Configure additional limits for all traffic to MMEs
To further protect the MMEs from a distributed attack, whereby a number of eNBs or FAPs are compromised, an AA FW can be configured to limit total traffic, not just from a single eNB as described in previous sections, but from all eNBs toward the MMEs.
It is recommended to configure the following three protection limits:
-
total bandwidth of SCTP toward MMEs
-
total number of flows toward MMEs
-
flow setup rate toward the MMEs
The configuration is as follows:
configure
application-assurance
group 1 create
policer "limit_total_sctp_bw" type single-bucket-bandwidth
granularity system create
rate 1200
mbs 100
exit
policer "limit_total_sctp_flows" type flow-count-limit
granularity system create
flow-count 400
exit
policer "limit_total_sctp_flows_rate" type flow-rate-limit
granularity system create
rate 100
mbs 100
exit
-
The policers are of type system and not subscriber to be applied to all eNBs or FAPs, as is the case when auto-transit subscribers are created (see 1 Divert AA traffic and apply basic firewall rules).
-
The actual limits of these policers are a function of the total number of eNBs served by the SeGW. In the preceding configuration, it is assumed that there are 400 eNBs. Therefore, the total limit is 400 flows of SCTP traffic.
-
A flow setup rate limit of 100 is set to protect MMEs from a storm of new SCTP flows.
The policers are then referenced from within the appropriate AQP entry that matches the MMEs traffic and SCTP:
configure
application-assurance
group 1:1 create
policy
begin
app-qos-policy
entry 110 create
description " limit system traffic towards MMEs"
match
traffic-direction subscriber-to-network
src-ip eq ip-prefix-list "ALL_eNBs"
dst-ip eq ip-prefix-list "MMEs"
exit
action
bandwidth-policer "limit_total_sctp_bw"
flow-rate-limit "limit_total_sctp_flows_rate"
flow-count-limit "limit_total_sctp_flows"
exit
no shutdown
It is possible, but redundant, to add the ip-protocol eq sctp command as a match condition, because the configured session filter already ensures that only SCTP traffic can flow between eNBs and MMEs.
2.5 Allow only specified SCTP PPIDs toward the MMEs
In this step, the operator blocks all except the specified SCTP messages that contain configured PPIDs, using an AA SCTP filter configuration:
*A:SeGW-2>config>app-assure>group# sctp-filter ?
- no sctp-filter <sctp-filter-name>
- sctp-filter <sctp-filter-name> [create]
<sctp-filter-name> : [32 chars max]
<create> : keyword
[no] description - Configure a description of the SCTP filter
[no] event-log - Configure an event log for packets dropped
by the SCTP filter
ppid + Configure actions for specific or default PPIDs
(Payload Protocol Identifiers)
[no] ppid-range - Configure the range of allowable PPIDs
for the SCTP filter
The filter specifies either a range of PPIDs or individual PPIDs:
*A:SeGW-2>config>app-assure>group>sctp-fltr>ppid# entry 1 ?
- entry <entry-id> value <ppid-value> action {permit|deny}
- no entry <entry-id>
<entry-id> : [1..255]
<ppid-value> : [0..4294967295]D | [80 chars max]
<permit|deny> : permit|deny
The PPIDs can be specified either by their values or by names. Names are specified in RFC 4960. See SCTP PPIDs .
|
Value |
SCTP PPID |
Value |
SCTP PPID |
|---|---|---|---|
|
0 |
Reserved by SCTP |
31 |
Service Area Broadcast Protocol (SABP) |
|
1 |
IUA |
32 |
Fractal Generator Protocol (FGP) |
|
2 |
M2UA |
33 |
Ping Pong Protocol (PPP) |
|
3 |
M3UA |
34 |
CalcApp Protocol (CALCAPP) |
|
4 |
SUA |
35 |
Scripting Service Protocol (SSP) |
|
5 |
M2PA |
36 |
NetPerfMeter Protocol Control Channel (NPMP-CONTROL) |
|
6 |
V5UA |
37 |
NetPerfMeter Protocol Data Channel (NPMP-DATA) |
|
7 |
H.248 |
38 |
Echo (ECHO) |
|
8 |
BICC/Q.2150.3 |
39 |
Discard (DISCARD) |
|
9 |
TALI |
40 |
Daytime (DAYTIME) |
|
10 |
DUA |
41 |
Character Generator (CHARGEN) |
|
11 |
ASAP |
42 |
3GPP RNA |
|
12 |
ENRP |
43 |
3GPP M2AP |
|
13 |
H.323 |
44 |
3GPP M3AP |
|
14 |
Q.IPC/Q.2150.3 |
45 |
SSH over SCTP |
|
15 |
SIMCO <draft-kiesel-midcom-simco-sctp-00.txt> |
46 |
Diameter in a SCTP DATA chunk |
|
16 |
DDP Segment Chunk |
47 |
Diameter in a DTLS/SCTP DATA chunk |
|
17 |
DDP Stream Session Control |
48 |
R14P. BER Encoded ASN.1 over SCTP |
|
18 |
S1 Application Protocol (S1AP) |
49 |
Unassigned |
|
19 |
RUA |
50 |
WebRTC DCEP |
|
20 |
HNBAP |
51 |
WebRTC String |
|
21 |
ForCES-HP |
52 |
WebRTC Binary Partial (deprecated) |
|
22 |
ForCES-MP |
53 |
WebRTC Binary |
|
23 |
ForCES-LP |
54 |
WebRTC String Partial (deprecated) |
|
24 |
SBc-AP |
55 |
3GPP PUA |
|
25 |
NBAP |
56 |
WebRTC String Empty |
|
26 |
Unassigned |
57 |
WebRTC Binary Empty |
|
27 |
X2AP |
58-4294967295 |
Unassigned |
|
28 |
IRCP - Inter Router Capability Protocol |
||
|
29 |
LCS-AP |
||
|
30 |
MPICH2 |
Nokia recommends to limit the SCTP traffic to only those packets with S1 AP PPID. The SCTP filter can be configured to deny all by default and only allow PPID S1 AP (by value 18 or by name s1-application-protocol) as follows:
configure
application-assurance
group 1:1 create
sctp-filter "SCTP-PPID-Filter" create
description "Allow only S1AP PPID"
event-log "FW_drops_log"
ppid
default-action deny
entry 1 value "s1-application-protocol" action permit
exit
This configured SCTP filter is then referenced as an action from within an AQP entry:
configure
application-assurance
group 1:1 create
policy
begin
app-qos-policy
entry 100 create
description "limit SCTP traffic"
match
traffic-direction subscriber-to-network
ip-protocol-num eq sctp
exit
action
bandwidth-policer "sctp_bw_limit"
flow-count-limit "sctp_flow_count"
sctp-filter "SCTP-PPID-Filter"
exit
no shutdown
exit
The following command shows the packets allowed or denied by the configured SCTP filter:
*A:SeGW-2# show application-assurance group 1:1 sctp-filter "SCTP-PPID-Filter"
===============================================================================
Application Assurance Group 1:1 SCTP Filter "SCTP-PPID-Filter"
===============================================================================
Description : Allow only S1AP PPID
Maximum PPID : 4294967295
Minimum PPID : 0
Default action : deny
Configured PPIDs : 1
Packets arrived : 0
Packets denied
Malformed packet : 0
PPID out of range : 0
PPID denied : 0
Packets permitted : 0
===============================================================================
The SCTP malformed packet counter shown above increments when an AA SCTP filter encounters an SCTP packet that is malformed, such as:
-
IP packet is too small to contain a common SCTP header
-
SCTP chunk LEN < 4 bytes: each SCTP chunk header is 4 bytes, so the SCTP chunk cannot be smaller than this
-
remaining space in the IP packet is too small to contain a chunk header (for example, your packet has 2 chunks and the 2nd chunk length goes beyond the IP length advertised)
-
IP packet is too small to contain the chunk
The SCTP filter statistics cannot be reset while processing without disabling the SCTP filter.
Another way to view the effect of the configured SCTP filter is to check the firewall log, if configured:
*A:SeGW-2# tools dump application-assurance group 1:1 event-log "FW_drops_log" isa 1/2
=====================================================
Application-Assurance event-log "FW_drops_log"
Current Time: "06/12/2025 07:12:50" (UTC)
group[:partition]: 1:1
isa: 1/2
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
Total Records: 0
=====================================================
3 Configure AA-ISA to protect SGW (GTP-U traffic)
While GTP filtering is very different from SCTP filtering, the configuration to limit the flow counts, bandwidth, and session filter is similar.
3.1 Create an AA IP list for SGWs
In addition to the lists configured in 2.1 Create IP AA lists, the operator can optionally configure a list that contains the SGW IP addresses that are served by the SeGW, in case there is more than one.
configure
application-assurance
group 1:1 create
ip-prefix-list "SGWs" create
description "Serving Gateways IPs"
prefix 172.16.111.1/32
prefix 172.16.111.2/32
exit
3.2 Allow only GTP-U traffic toward SGWs — no port scanning
Similar to 2.2 Allow only SCTP traffic toward MMEs — no port scanning, create an GTP filter to allow only GTP traffic to/from eNBs to SGWs:
configure
application-assurance
group 1:1 create
session-filter "SeGW_FW"
default-action deny event-log "FW_drops_log"
---snip---
entry 2 create
description "allow GTP-u to SGWs"
match
ip-protocol-num udp
src-ip ip-prefix-list "ALL_eNBs"
dst-ip ip-prefix-list "SGWs"
dst-port eq 2152
exit
action permit
exit
The following session filter needs to be added to the default sub-policy AQP, similar to 2.2 Allow only SCTP traffic toward MMEs — no port scanning:
configure
application-assurance
group 1:1 create
policy
begin
app-qos-policy
entry 500 create
description "apply SeGW session filter rules"
match
traffic-direction subscriber-to-network
exit
action
bandwidth-policer "limit_eNBs_total_bw"
flow-count-limit "limit_eNBs_total_Flows"
session-filter "SeGW_FW"
overload-drop
error-drop
fragment-drop all
exit
no shutdown
exit
For AA to recognize GTP traffic and perform sanity packet checking, configure a GTP filter at the group partition level:
configure
application-assurance
group 1:1 create
gtp
no shutdown
exit
3.3 DoS protection — limit the number of GTP-U flows from eNBs
AA can be configured to limit the number of GTP flows from an eNB. A GTP-U flow is defined by GTP-U packet destination IP + tunnel ID (TEID).
AA allows the operator to configure two limits: one that applies to the each eNB and one that applies for all GTP-U traffic from all eNBs:
configure
application-assurance
group 1 create
policer "GTPu-Flow-count-limit" type flow-count-limit
granularity subscriber create
flow-count 800
gtp-traffic
exit
The actual value of the flow count limit is a function of the number of UEs or devices served by an eNB or FAP. In the preceding case, it is assumed that there are 100 devices with a maximum of 8 GTP-U flows per device. For FAP, the number is typically around 32 devices per FAP.
Assuming that there are 1000 eNBs or FAPs that are served by the SeGW, then to limit the total number of GTP-U flows, the operator can apply the following system policer with granularity system:
configure
application-assurance
group 1 create
policer "limit_total_GTPU_Flow_count" type flow-count-limit
granularity system create
flow-count 800000
gtp-traffic
exit
Configure AQPs to execute the policers:
configure
application-assurance
group 1:1 create
policy
begin
app-qos-policy
entry 120 create
description "limit GTP-U traffic"
match
traffic-direction subscriber-to-network
exit
action
flow-count-limit "GTPu-Flow-count-limit"
exit
no shutdown
exit
entry 130 create
description "limit TOTAL GTPU towards SGWs"
match
traffic-direction subscriber-to-network
exit
action
flow-count-limit "limit_total_GTPU_Flow_count"
exit
no shutdown
exit
For GTP-U flow count policing, it is important that aqp-initial-lockup is enabled:
configure
application-assurance
group 1:1 create
aqp-initial-lookup
The preceding configured limits are applied only to upstream traffic, to protect the network. No limit is placed on the downstream traffic toward the eNBs.
For small cell deployments, the number of GTP-U tunnels per FAP is a function of:
-
deployment mode:
-
residential = 32 UEs
-
enterprise = 8 UEs
-
-
number of guaranteed bit rate (GBR) tunnels (max 8) and non-GBR tunnels (max 8) per UE.
Therefore, the GTP-U tunnel limit per FAP should be set to 32 x 8 = 256 for residential deployments or 8 x 8 = 64 for enterprise deployments.
The operator can view the effect of the configured policers on GTP traffic by running the following show command:
*A:SeGW-2# show application-assurance group 1:1 gtp
===============================================================================
Application Assurance Group 1:1 GTP
===============================================================================
Admin status : Up
Event log : (Not Specified)
Event log action : deny
Mode : filtering
GTP-C inspection : Disabled
-------------------------------------------------------------------------------
GTP Statistics sub-to-net net-to-sub
-------------------------------------------------------------------------------
Incoming packets 0 0
Packets denied
UDP packet length 0 0
GTP message length 0 0
GTP version 0 0
-------------------------------------------------------------------------------
Packets permitted 0 0
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
GTP Policing Statistics sub-to-net net-to-sub
-------------------------------------------------------------------------------
Packets arrived 0 0
Packets denied
gtp-traffic flow-count policer 0 0
Other 0 0
-------------------------------------------------------------------------------
Packets permitted 0 0
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
GTP Filter Statistics sub-to-net net-to-sub
-------------------------------------------------------------------------------
Packets arrived 0 0
Packets denied 0 0
Packets permitted
gtp-filter 0 0
no gtp-filter 0 0
-------------------------------------------------------------------------------
Total GTP packets permitted 0 0
===============================================================================
In the last section shown above, GTP filter statistics are related to GTP filters that are discussed and configured later in 3.5 Further GTP filtering and validation of this chapter.
3.4 DoS protection — limit the GTP-U bandwidth from eNBs
This step is similar to 3.3 DoS protection — limit the number of GTP-U flows from eNBs, but instead of configuring a flow count policer, the operator configures bandwidth policers:
configure
application-assurance
group 1 create
policer "GTPU_bw_limit" type single-bucket-bandwidth
granularity subscriber create
rate 5000
mbs 100
exit
policer "limit_total_GTPU_bw" type single-bucket-bandwidth
granularity system create
rate 2000000
mbs 2000
exit
configure
application-assurance
group 1:1 create
policy
begin
app-qos-policy
entry 120 create
description "limit GTP-U traffic"
match
traffic-direction subscriber-to-network
exit
action
bandwidth-policer "GTPU_bw_limit"
flow-count-limit "GTPu-Flow-count-limit"
exit
no shutdown
exit
entry 130 create
description "limit TOTAL GTPU towards SGWs"
match
traffic-direction subscriber-to-network
exit
action
bandwidth-policer "limit_total_GTPU_bw"
flow-count-limit "limit_total_GTPU_Flow_count"
exit
no shutdown
exit
The preceding configured limits are applied only to upstream traffic, to protect the network. No limit is placed on downstream traffic toward the eNB.
As a debugging tool, the operator can use the AA flow-record-search command to check the status of GTP flows through the ISA:
*A:SeGW-2# tools dump application-assurance group 1:1 flow-record-search isa 1/2
flow-status active protocol "gtp"
=====================================================
Application-Assurance flow record search
Search Start Time: "06/12/2025 08:02:55" (UTC)
Search Criteria:
group[:partition]: 1:1
isa: 1/2
protocol name: "gtp"
application name: none specified
app-group name: none specified
flow-status: active
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)
SEARCH COMPLETED.
Search End Time: "06/12/2025 08:02:55" (UTC)
Total Records: 0
=====================================================
GTP flows that are to be denied by the previous AA configurations should not appear in the search results.
3.5 Further GTP filtering and validation
AA allows the operator to configure a GTP filter to enforce which GTP message types are allowed/denied, as well as the maximum allowed GTP message length:
*A:SeGW-2>config>app-assure>group>gtp# gtp-filter ?
- gtp-filter <gtp-filter-name> [create]
- no gtp-filter <gtp-filter-name>
<gtp-filter-name> : [32 chars max]
<create> : keyword
[no] description - Configure a description of the GTP filter
[no] event-log - Configure an event log for packets dropped by the GTP filter
[no] gtp-in-gtp - Configure the default action for GTP in GTP packets
---snip---
[no] max-payload-le* - Configure the maximum payload length of the GTP filter
message-type + Configure actions for specific or default messages
---snip---
An AA GTP filter allows the operator to configure a maximum payload size for the GTP traffic. However, in this configuration example, no maximum payload size is configured.
The list of GTP message types are defined by 3GPP standard 3GPP TS 29.281 as per GTP messages .
|
Message type value (decimal) |
Message |
Message type value (decimal) |
Message |
|---|---|---|---|
|
1 |
echo-request |
55 |
forward-relocation-complete |
|
2 |
echo-response |
56 |
relocation-cancel-request |
|
3 |
version-not-supported |
57 |
relocation-cancel-response |
|
4 |
node-alive-request |
58 |
forward-sms-context |
|
5 |
node-alive-response |
59 |
forward-relocation-complete-acknowledge |
|
6 |
redirection-request |
60 |
forward-sms-context-acknowledge |
|
7 |
redirection-response |
70 |
ran-information-relay |
|
16 |
create-pdp-context-request |
96 |
mbms-notification-request |
|
17 |
create-pdp-context-response |
97 |
mbms-notification-response |
|
18 |
update-pdp-context-request |
98 |
mbms-notification-reject-request |
|
19 |
update-pdp-context-response |
99 |
mbms-notification-reject-response |
|
20 |
delete-pdp-context-request |
100 |
create-mbms-context-request |
|
21 |
delete-pdp-context-response |
101 |
create-mbms-context-response |
|
22 |
initiate-pdp-context-activation-request |
102 |
update-mbms-context-request |
|
23 |
initiate-pdp-context-activation-response |
103 |
update-mbms-context-response |
|
26 |
error-indication |
104 |
delete-mbms-context-request |
|
27 |
pdu-notification-request |
105 |
delete-mbms-context-response |
|
28 |
pdu-notification-response |
112 |
mbms-registration-request |
|
29 |
pdu-notification-reject-request |
113 |
mbms-registration-response |
|
30 |
pdu-notification-reject-response |
114 |
mbms-de-registration-request |
|
31 |
supported-extension-headers-notification |
115 |
mbms-de-registration-response |
|
32 |
send-routing-information-for-gprs-request |
116 |
mbms-session-start-request |
|
33 |
send-routing-information-for-gprs-response |
117 |
mbms-session-start-response |
|
34 |
Failure-report-request |
118 |
mbms-session-stop-request |
|
35 |
failure-report-request |
119 |
mbms-session-stop-response |
|
36 |
note-ms-gprs-present-request |
120 |
mbms-session-update-request |
|
37 |
note-ms-gprs-present-response |
121 |
mbms-session-update-response |
|
48 |
identification-request |
128 |
ms-info-change-notification-request |
|
49 |
identification-response |
129 |
ms-info-change-notification-response |
|
50 |
sgsn-context-response |
240 |
data-record-transfer-request |
|
51 |
sgsn-context-request |
241 |
data-record-transfer-response |
|
52 |
sgsn-context-acknowledge |
254 |
end-marker |
|
53 |
forward-relocation-request |
255 |
g-pdu |
|
54 |
forward-relocation-response |
- echo-request
- echo-response
- echo-indication
- g-pdu
- end-marker
- supported-extension-headers-notification
If these message types are permitted by the configured GTP filter, AA performs extensive GTP-U header checking on these six types.
If no GTP filter is configured, no extensive GTP-U header checks are performed. For example, if the operator wants to allow all GTP-U packets and perform all GTP header sanity checks, then a GTP filter that allows all message types needs to be configured, with the default action of permit and with no values, as follows:
configure
application-assurance
group 1:1 create
gtp
gtp-filter "allow-all" create
message-type
default-action permit
exit
Because AA FW in an SeGW is protecting an S1-U interface running GTP-U, the GTP filter only needs to allow the six GTP messages that are permitted for GTP-U:
configure
application-assurance
group 1:1 create
gtp
gtp-filter "filter-gtp-msgs" create
description "allow only certain msg types"
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
This GTP filter is then referenced from within an AQP entry action, as follows, in order for it to take effect:
configure
application-assurance
group 1:1 create
policy
begin
app-qos-policy
entry 120 create
description "limit GTP-U traffic"
match
traffic-direction subscriber-to-network
dst-ip eq ip-prefix-list "SGWs"
exit
action
bandwidth-policer "GTPU_bw_limit"
flow-count-limit "GTPu-Flow-count-limit"
gtp-filter "filter-gtp-msgs"
exit
no shutdown
exit
The operator can view the effect of the configured GTP filter on S1-U traffic using the following show routine:
*A:SeGW-2# show application-assurance group 1:1 gtp gtp-filter "filter-gtp-msgs"
===============================================================================
Application Assurance Group 1:1 GTP Filter "filter-gtp-msgs"
===============================================================================
Description : allow only certain msg types
Maximum payload length : (Not Specified)
Event log : (Not Specified)
Event log action : deny
Default action : deny
Default GTPv2 action : permit
Default IMSI-APN action : permit
GTP in GTP action : permit
Validate GTP tunnels : disabled
Validate sequence number : disabled
Validate source IP address : disabled
GTP tunnel endpoint limit : (Not Specified)
Configured messages : 6
Configured GTPv2 messages : 0
Configured IMSI-APN filters : 0
Packets arrived : 0
Packets denied
Payload length : 0
Message type : 0
GTPv2 message type : 0
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 : 0
===============================================================================
The preceding output is in addition to the information provided by the overall GTP show command:
show application-assurance group 1:1 gtp4 Configure AA-ISA to protect NMS (OAM traffic)
4.1 Create an IP AA prefix list that contains the NMS server IP addresses
The following command configures IP prefix list "NMSs" with IP prefix 172.16.120.0/30:
configure
application-assurance
group 1:1 create
ip-prefix-list "NMSs" create
description "Network Management-OAM subnet"
prefix 172.16.120.0/30
exit
In the case of small cell deployments, different NMS servers need to be configured
4.2 Allow eNBs to initiate FTP- and ICMP-only traffic toward NMS, block port scanning
The following entries are added to the session filter "SeGW_FW":
configure
application-assurance
group 1:1 create
session-filter "SeGW_FW" create
default-action deny event-log "FW_drops_log"
---snip---
entry 3 create
description "allow FTP to NMS"
match
ip-protocol-num tcp
src-ip ip-prefix-list "ALL_eNBs"
dst-ip ip-prefix-list "NMSs"
dst-port eq 22
exit
action permit
exit
entry 4 create
description "allow ICMP to NMS"
match
ip-protocol-num icmp
src-ip ip-prefix-list "ALL_eNBs"
dst-ip ip-prefix-list "NMSs"
exit
action permit
exit
The operator can view the effect of the session filter on traffic, in terms of how many times it is applied, using the following show routine:
*A:SeGW-2# show application-assurance group 1:1 session-filter
===============================================================================
AA Session Filter Table
===============================================================================
Name Default Action Referenced Entries
-------------------------------------------------------------------------------
SeGW_FW deny aqp 4
-------------------------------------------------------------------------------
No. of session filters: 1
===============================================================================
*A:SeGW-2# show application-assurance group 1:1 session-filter "SeGW_FW"
===============================================================================
AA Session Filter Instance "SeGW_FW"
===============================================================================
Description : (Not Specified)
Default Action : deny
Event Log : FW_drops_log
AQP Entries :
500
-------------------------------------------------------------------------------
Filter Match Criteria
-------------------------------------------------------------------------------
Entry : 1
Description : allow SCTP to MMEs
IP Protocol : sctp
Source IP List : ALL_eNBs
Dest IP List : MMEs
Dest Port : eq 6005
Action : permit
Event Log : (Not Specified)
Hits : 0 flows
-------------------------------------------------------------------------------
Entry : 2
Description : allow GTP-u to SGWs
IP Protocol : udp
Source IP List : ALL_eNBs
Dest IP List : SGWs
Dest Port : eq 2152
Action : permit
Event Log : (Not Specified)
Hits : 0 flows
-------------------------------------------------------------------------------
Entry : 3
Description : allow FTP to NMS
IP Protocol : tcp
Source IP List : ALL_eNBs
Dest IP List : NMSs
Dest Port : eq 22
Action : permit
Event Log : (Not Specified)
Hits : 0 flows
-------------------------------------------------------------------------------
Entry : 4
Description : allow ICMP to NMS
IP Protocol : icmp
Source IP List : ALL_eNBs
Dest IP List : NMSs
Action : permit
Event Log : (Not Specified)
Hits : 0 flows
-------------------------------------------------------------------------------
No. of entries : 4
===============================================================================
The preceding configuration is generic and may need to be modified to suit the deployment requirements. For example, in the case of small cell SeGW deployment, traffic on other ports needs to be allowed to/from different NMS type servers, such as allowing TCP port 7003 and port 7013 to Home Device Manager (HDM) servers. This can be accomplished by configuring additional entries in the preceding session filter.
By allowing port 22 for FTP, the AA FW automatically opens and closes the associated data channel ports. For more information about AA FW capabilities, with regard to OAM FW protection, see Application Assurance — Stateful Firewall.
Conclusion
The SR OS AA stateful firewall feature runs on AA-ISA and extends application-level analysis to provide an in-line stateful service, integrated within the Security Gateway (SeGW).
AA stateful packet filtering, combined with AA layer 7 classification and control, provides advanced, next-generation firewall functionality, protecting mobile network core infrastructure, such as MMEs, SGWs, and NMSs.