S1-U GTP traffic protection

protection against malformed GTP packets attack. For GTP-v1 traffic carried over UDP port number port 2152, AA performs various packet sanity checks, such as:

UDP destination port is 2152
version (GTP-U should always be version 1)
protocol type bit should be 1
invalid/missing mandatory header fields
invalid optional/spare header fields
invalid/missing header extensions
invalid length

For S1-U interface, only GTP-v1 is supported. No support for GTP-v2 (as there is no signaling on S1-U interface).

Details of the various GTP sanity checks that are performed for different GTP-U message types are shown in Table: GTP-U message types .

Table: GTP-U message types
Payload size	Encapsulated data checks	IE checks	Header extension checks	Optional HEADER check	GTP mandatory header checks
				If E, S or PN =1	Length	TEID	Spare	PT	Version
>0	PayloadSize is assumed to be the size of the remainder of the packet, unless the packet is fragmented No checking of the encapsulated data	No checks	Valid types = Service Class Indicator and PDCP PDU Number Extension size= 4*# of extensions	OptionalSize = 8 IF E= 0, ExtSize = 0	Optional Size + Extension Size + Payload Size	<>0	0	1	1	G-PDU (Encapsulated Data Delivery) – Message Type 255
	No payload after the IEs	Only private extensions are allowed.	No external header allowed.	No option headers allowed.	IE Size	0	0	1		Echo Request – Message Type 1
	No payload after the IEs	Recovery ID is present Private extensions allowed.	No external header allowed.	No option headers allowed.	IE Size	0	0	1	1	Echo Response – Message Type 2
	No payload after the IEs	Extension Header Type List IE is present Private extensions allowed No checking on the extension header value	No external header allowed.	No option headers allowed.	IE Size	0	0	0	1	Supported Extension Headers Notification - Message Type 31
	No payload after the IEs	TEID IE and GTP-U Peer Address IE are present IE type and length are verified Private extensions allowed	Only the UDP Port Extension Header is valid	OptionalSize = 8	Optional Size + Extension Size +IE Size	<>0	0	1	1	Error Indication – Message Type 26
	No payload after the IEs	Only Private extensions are allowed	no valid external header allowed.	OptionalSize = 8 IF E = 0, ExtSize = 0	IE Size	<>0	0	1	1	End Marker – Message Type 254

To enable GTP packet sanity checks, the operator must configure:

        config>app-assure>group <aa-group-id>[:<partition>]

When the gtp command is issued for a partition, AA treats traffic with UDP destination port number 2152 as GTP. It applies the different GTP level firewall functions as configured by the operator. However, it does not look beyond the GTP header for further inner L3-L7 packet classifications and actions. For example, Ipfix record for GTP traffic contains the 5 tuples of the GTP-u tunnel (eNB, SGW IPs and port numbers, and so on, no TEID).

protection against unsupported GTP messages

AA allows the operator to configure a GTP filter to indicate which GTP message types are to be allowed/denied as well as the maximum allowed GTP message length:

        config>app-assure>group <aa-group-id>[:<partition>]>gtp
                 gtp-filter <gtp-filter-name> [create]
                    max-payload-length <bytes>           //[0..65535]
                    message-type
                     default-action {permit|deny}
                     entry <entry-id> value <gtp-message-value> action {permit|deny}

There are approximately 67 valid message names to enter in the above GTP filter. Both names and numbers are accepted as input (for user convenience), but the CLI info always shows the name:

echo-request, echo-response, error-indication, g-pdu, end-marker and supported-extension-headers-notification.

After a GTP filter is configured, it can then be included as an AQP action:

        config>app-assure>group <aa-group-id>[:<partition>]> policy
               app-qos-policy
                   entry <entry-id> [create]
                      action
                        gtp-filter <gtp-filter-name>

extensive GTP header sanity checks (included in Table: GTP-U message types ) that are based on different GTP message types are only performed when these GTP messages are permitted by the GTP filter. If no GTP filter is configured, then no extensive GTP-U header checks are performed. In other words, if the operator wants to allow all GTP-U packets and perform all GTP header sanity checks, then the operator needs to configure a GTP filter with default action of permit and no values, such as:

        config>app-assure>group 1:100> gtp
               gtp-filter ‟allow-all” create
                   message-type
                      default-action permit

protection against flooding attacks; AA can be configured to drop all fragments and/or out of order fragments, using AQP action: fragment-drop {all | out-of-order}.

In the case that the IP fragment-drop command is not set, then the following conditions apply to the way AA inspects GTP traffic:

Permit/deny decisions are entirely based on the first fragment. The first fragment contains the entire GTP header in almost all of the cases.
Max packet length check is not done across fragments. Only the first fragment length is checked. In other words, AA ISA may allow a packet that is larger than the max packet allowed if it is fragmented, with the first fragment smaller than the configured maximum packet size allowed.
First fragmented packet is discarded (and logged), as well as subsequent fragments:
- If the first packet is too small to contain the mandatory header (12 bytes, ending with the TEID).
- If the mandatory header indicates there should be an optional header, and the fragment is too small to contain the optional header (mandatory + optional = 16 bytes).

GTP-in-GTP protection; GTP-in-GTP is a spoofing method that uses GTP-in-GTP encapsulation. After receiving the GTP packet in the upstream, the Serving GPRS Support Node (SGSN) encodes the packet again and forwards the packet to the Gateway GPRS Support Node (GGSN), through the relative PDP context. The embedded GTP packet may get decoded by the GGSN and allow an attacker to spoof GTP packets.

AA provides a mechanism to detect and drop GTP-in-GTP GTP-U packets:

        *A:Dut-C>config>app-assure>group>gtp# 
        +---gtp-filter <gtp-filter-name> [create]
        |   +---gtp-in-gtp {permit|deny}

By default, GTP-in-GTP checking is disabled.