Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.117  Word version:  17.2.0

Top   Top   Up   Prev   Next
1…   4.2…   4.2.3…   4.2.3.4…   4.2.3.5…   4.2.4…   4.3…   4.3.4…   4.4… 
4.2.4 Operating systems  4.2.4.1.1 Availability and Integrity  4.2.4.1.2 Authentication and Authorization  4.2.4.2.1 General  4.2.4.2.2 System account identification  4.2.5 Web Servers  4.2.5.2.1 Webserver logging  4.2.6 Network Devices  4.2.6.2.1 Packet filtering  4.2.6.2.2 Interface robustness requirements  4.2.6.2.3 GTP-C Filtering  4.2.6.2.4 GTP-U Filtering 
...

 

4.2.4  Operating systems  p. 48

4.2.4.1  General operating system requirements and related test cases  p. 48

4.2.4.1.1  Availability and Integrity  p. 48
4.2.4.1.1.1  Handling of growing content   p. 48
Requirement Name:
Growing (dynamic) content shall not influence system functions.
Requirement Description:
Growing or dynamic content (e.g. log files, uploads) shall not influence system functions. A file system that reaches its maximum capacity shall not stop a system from operating properly. Therefore, countermeasures shall be taken such as usage of dedicated filesystems, separated from main system functions, or quotas, or at least a file system monitoring to ensure that this scenario is avoided.
Test Case:
Test Name:
TC_HANDLING_OF_GROWING_CONTENT
Purpose:
To verify that the growing or dynamic content does not influence system functions.
Procedure and execution steps:
Pre-Conditions:
  1. Growing or dynamic content sources like e.g. log files and their paths are documented.
  2. Measures that are taken to protect system functions from growing or dynamic content that may exhaust file system capacity are documented.
  3. All logging capabilities that are not enabled by default are enabled manually as per the documentation instructions.
Execution Steps:
  1. Tester checks that the sources that are susceptible to being exhausted have been documented and measures aimed to counteract this are described.
  2. Tester enables monitoring of the system operation.
  3. Tester initiates traffic that causes increase of log files and monitors the system behaviour until the log file either reaches its quota or until file system is exhausted.
  4. In case file uploading is allowed (e.g. via SFTP) the tester initiates file uploading and tries to exhaust the file system.
Expected Results:
  1. It is verified that the taken measures are sufficient so that system operation is not influenced by growing or dynamic content at any case.
Expected format of evidence:
System monitoring data (e.g. Alarms, logs, CPU utilization, etc.).
Up
4.2.4.1.1.2  Handling of ICMP   p. 49
Requirement Name:
Processing of ICMPv4 and ICMPv6 packets
Requirement Description:
Processing of ICMPv4 and ICMPv6 packets which are not required for operation shall be disabled on the network product. In particular, there are certain types of ICMP4 and ICMPv6 that are not used in most networks, but represent a risk.
ICMP message types which on receipt lead to responses or to configuration changes are not mentioned in this requirement, but they may be necessary to support relevant and specified networking features. Those must be documented.
Certain ICMP types are generally permitted and do not need to be specifically documented. Those are marked as "Permitted" in below table.
The network product shall not send certain ICMP types by default, but it may support the option to enable utilization of these types (e.g. for debugging). This is marked as "Optional" in below table.
Type (IPv4) Type (IPv6) Description Send Respond to
0128Echo ReplyOptional (i.e. as automatic reply to "Echo Request")N/A
31Destination UnreachablePermittedN/A
8129Echo RequestPermittedOptional
113Time ExceededOptionalN/A
124Parameter ProblemPermittedN/A
N/A2Packet Too BigPermittedN/A
N/A135Neigbor SolicitationPermittedPermitted
N/A136Neighbor AdvertisementPermittedN/A
The network product shall not respond to, or process (i.e. do changes to configuration), under any circumstances certain ICMP message types as marked in below table.
Type (IPv4) Type (IPv6) Description Send Respond to Process (i.e. do changes to configuration)
5137RedirectN/AN/ANot Permitted
13N/ATimestampN/ANot PermittedN/A
14N/ATimestamp ReplyNot Permitted (i.e. as automatic reply to "Timestamp")N/AN/A
N/A133Router SolicitationN/ANot PermittedNot Permitted
N/A134Router AdvertisementN/AN/ANot Permitted
Test Case:
The test for this requirement can be carried out using a suitable tool or manually by performing the steps described below. If a tool is used then the tester needs to provide evidence, e.g. by referring to the documentation of the tool, that the tool actually provides functionality equivalent to the steps described below.
Test Name:
TC_HANDLING_OF_ICMP
Purpose:
To verify that the network product does not reply to certain ICMP types in accordance with the requirement. To verify that the network product does not send 'Time Exceeded'.
To verify that the network product does not process the following ICMPv4 and ICMPv6 types:
  • "Redirect (5)"
  • Router Solicitation
  • Router Advertisement
Procedure and execution steps:
Pre-Conditions:
  • The tester knows whether the network product supports IPv4 and/or IPv6:
  • If applicable, the tester has the needed system privileges for confirming that the ICMP messages with types "Not Permitted" to process are indeed not leading to configuration changes..
  • If applicable, the tester has the needed system privileges for confirming that certain ICMP message types are dropped by the network product on receipt.
  • A tester machine is available and equipped with a suitable ICMP packets generator tool.
Execution Steps:
The following needs to be done for all IP protocol versions (IPv4 and/or IPv6) supported by the network element.
For verifying that the network product does not reply to ICMP messages with types where this is not permitted: The tester sends samples of the applicable ICMP messages from the tester machine to the network product and verifies by appropriate means that
  • the messages are dropped on receipt by the network product (e.g. by means of appropriate firewall rules),
  • or no response is sent out towards the test machine,
  • or there are other means ensuring that the ICMP messages cannot trigger a response.
For verifying that the network product does not change its configuration due to receiving ICMP messages with types where this is not permitted: The tester sends samples of the applicable ICMP messages from the tester machine to the network product and verifies by appropriate means that
  • the messages are dropped on receipt by the network product (e.g. by means of appropriate firewall rules),
  • or the network product's applicable system configuration remains unchanged upon receipt of the messages,
  • or there are other means ensuring that the ICMP messages cannot lead to configuration changes.
The tester utilizes appropriate means to verify consistency between the documentation in regard to ICMP and the network product.
Expected Results:
The ICMP messages which are "Not Permitted" to generate a response from the network product do not generate a response.
The ICMP messages which are "Not Permitted" to change the configuration of the network element do not change the configuration.
ICMP message types which lead to responses or to configuration changes on receipt, if neither mentioned in the requirement nor in the documentation, are not enabled.
Expected format of evidence:
The following information needs to be retained and included into the report as appropriate:
  • Tools used and their configuration
  • Tool output
  • Test result (Passed or not)
Up
4.2.4.1.1.3  Handling of IP options and extensions   p. 51
Requirement Name:
IP packets with unnecessary options or extension headers shall not be processed.
Requirement Description:
IP packets with unnecessary options or extension headers shall not be processed. IP options and extension headers (e.g. source routing) are only required in exceptional cases. So, all packets with enabled IP options or extension headers shall be filtered.
Test Case:
The test for this requirement can be carried out using a suitable tool or manually by performing the steps described below. If a tool is used then the tester needs to provide evidence, e.g. by referring to the documentation of the tool, that the tool actually provides functionality equivalent to the steps described below.
Test Name:
TC_HANDLING-IP-OPTIONS-AND-EXTENSIONS
Purpose:
To verify that the network product provides functionality to filter out IP packets with unnecessary options or extension headers.
Procedure and execution steps:
Pre-Conditions:
  • The manufacturer declares in the documentation accompanying the network product at least the following information:
  • The support of filtering capability for IP packets with unnecessary options or extensions headers.
  • The actions performed by the network product when an IP packet with unnecessary options or extensions headers is received (e.g. the packet is dropped, the options or extensions are ignored and the packet is treated as if it has no IP options, etc.) .
  • Guidelines on how to enable and configure this filtering capability.
  • The network product has at least one physical interface named if1 supporting both IPv4 and IPv6. If the network product does not support IPv6 then IPv6 related steps and checks may be skipped.
  • A network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product is available .
  • The tester has administrative privileges.
  • A tester machine is available with a tool able to send IPv4 packets with the IP Options and IPv6 packets (if supported by the network product) with Extension Header set (e.g. Scapy).
Execution Steps:
  1. The tester logs in the network product.
  2. The tester configures on the network product a filtering rule to drop all IP packets containing an IP Option set
    1. The tester establishes an O&M session on if1 interface
    2. Using the tool (e.g. Scapy) the tester sends from the tester machine an IPv4 TCP SYN packet with an appropriate destination portto if1 interface without setting any IP Options
    3. Using the network traffic analyser, the tester verifies that the IP packet is received by the network product and the tester verifies that the corresponding ACK message is sent back.
    4. Using the tool (e.g. Scapy) the tester sends an IPv4 TCP SYN packet with an appropriate destination port and an IP Option set to the if1 interface
    5. Using the network traffic analyser, the tester verifies that the IP packet is received by the network product but no ACK message is sent back. This confirms the packet is dropped as expected from the filtering rule.
  3. The tester configures on the network product a filtering rule to drop all incoming packets based on specific Extension Header Types, e.g. packets with the Routing Header extension. Step 3 may be skipped if the network product does not support IPv6.
    1. Using the tool (e.g. Scapy) the tester sends from the tester machine an IPv6 TCP SYN packet with an appropriate destination port to if1 interface without setting any extension header
    2. Using the network traffic analyser, the tester verifies that the IP packet is received by the network product and the tester verifies that the corresponding ACK message is sent back.
    3. Using the tool (e.g. Scapy) the tester sends an IPv6 TCP SYN packet with an appropriate destination port and an extension header set to the if1 interface
    4. Using the network traffic analyser, the tester verifies that the IP packet is received by the network product but no ACK message is sent back. This confirms the packet is dropped as expected from the filtering rule.
Expected Results:
The network product discards IPv4 packets with unnecessary options or IPv6 packets (assuming the network product supports IPv6) with extension header.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
  • Used tools and their configurations
  • Settings and configurations used
  • Pcap trace
  • Screenshot
  • Test result (Passed or not)
Up
4.2.4.1.2  Authentication and Authorization  p. 53
4.2.4.1.2.1  Authenticated Privilege Escalation only   p. 53
Requirement Name:
There shall not be a privilege escalation method in interactive sessions (CLI or GUI) which allows a user to gain administrator/root privileges from another user account without re-authentication.
Requirement Description:
There shall not be a privilege escalation method in interactive sessions (CLI or GUI) which allows a user to gain administrator/root privileges from another user account without re-authentication.. Implementation example: Disable insecure privilege escalation methods so that users are required to (re-)login directly into the account with the required permissions.
Test Case:
Test Name:
TC_OS_PRIVILEGE
Purpose:
To ensure that privileged operating system functions shall not be used without successful authentication and authorization, and that violations of this requirement are documented and strictly limited in number and functionality.
Procedure and execution steps:
Pre-Conditions:
  1. The manufacturer shall provide documentation of the operating system(s) used in the network product.
  2. The manufacturer shall supply a list "A" of operating system functions which a system user can use to explicitly gain higher privileges, and how these functions are configured. Unix® example: sudo command and its configuration file /etc/sudoers.
  3. The manufacturer shall supply a list "B" of operating system commands, GUI functions, and files which will execute specifically limited tasks automatically with higher privileges, even when used by a low-privileged user. List "B" shall also contain:
    • configuration of these commands and GUI functions;
    • owner and permission settings of files;
    • justification for having the command, GUI function or file on the network product
      Unix® example: root-owned files with SUID and SGID permissions.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
  1. The tester logs into the network product and verifies that list "A" is accurate, based on his expert knowledge of the operating system(s) used in the network product, and operating system documentation.
  2. The tester verifies that entries in the list "A" require successful authentication for all users without exception, on basis of the user name and at least one authentication attribute.
  3. The tester logs into the network product and verifies that list "B" is accurate, based on his expert knowledge of the operating system(s) used in the network product, and operating system documentation. Unix® example: To list files with SUID and SGID permissions, the following commands can be used:
    SUID: find / -perm -4000 -type f -exec ls {} \; > suid_files.txt
    SGID: find / -perm -2000 -type f -exec ls {} \; > sgid_files.txt
  4. The tester verifies that file entries in the list "B" do not have write permissions for anyone else than the owner.
  5. The tester verifies that entries in the list "B" only allow execution of specifically limited tasks which are needed on this network product, based on his expert knowledge of the operating system(s) used in the network product, and operating system documentation.
  6. The tester logs into the network product and tests for every entry in the list "B" that it does not provide a means to execute arbitrary functions with administrator/root privileges, e.g. via a shell escape.
Expected Results:
  1. The network product does not allow a user to gain administrator/root privileges from another user account without re-authentication.
  2. If a network product provides functions and files which execute specifically limited tasks automatically with higher privileges, it ensures that these limits cannot be bypassed.
  3. The system documentation about means for a user to gain administrator/root privileges from another user account accurately describes the network product.
Expected format of evidence:
A test report provided by the accredited evaluator's test lab which will consist of the following information:
  • Documentation provided by the vendor: lists "A" and "B"
  • Description of executed tests and commands
  • Relevant output (e.g. screenshot or terminal log)
  • Test result (passed or not passed)
Up

4.2.4.2  UNIX® specific requirements and related test cases  p. 54

4.2.4.2.1  General  p. 54
4.2.4.2.2  System account identification  p. 54
Requirement Name:
System account identification
Requirement Description:
Each system account in UNIX® shall have a unique UID.
Security Objective references:
tba.
Test case:
Test Name:
TC_UNIQUE_SYSTEM_ACCOUNT_IDENTIFICATION
Purpose:
To verify that UNIX® account UIDs are assigned uniquely.
Procedure and execution steps:
Pre-Conditions:
UNIX® is used on the MME.
Execution Steps:
  1. Create several UNIX® accounts.
  2. Check UIDs of created accounts and of existing system accounts and, in particular, the root account.
Expected Results:
The UIDs are all different and, in particular, only the root account has UID = 0.
Up

4.2.5  Web Servers  p. 55

4.2.5.1  HTTPS  p. 55

Requirement Name:
HTTPS
Requirement Description:
The communication between Web client and Web server shall be protected using TLS. The TLS profile defined in Annex E of TS 33.310 shall be followed with the following modifications:
Cipher suites with NULL encryption shall not be supported
Security Objective references:
tba.
Test case:
Test Name:
HTTPS
Purpose:
Verify the above requirement.
Procedure and execution steps, expected results, expected format of evidence:
These are the same as for the test case in clause 4.2.3.2.4, except that, for execution step 2, it is tested that NULL encryption is not supported.
Up

4.2.5.2  Logging  p. 55

4.2.5.2.1  Webserver logging  p. 55
Requirement Name:
Webserver logging
Requirement Description:
Access to the webserver shall be logged. The web server log shall contain the following information:
  • Access timestamp
  • Source (IP address)
  • (Optional) Account (if known)
  • (Optional) Attempted login name (if the associated account does not exist)
  • Relevant fields in http request. The URL should be included whenever possible.
  • Status code of web server response
Security Objective references:
tba.
Test case:
Test Name:
TC_WEBSERVER_LOGGING
Purpose:
Verify that all accesses to the webserver are logged with the required information.
Procedure and execution steps:
Pre-Condition:
Network Product documentation which contains information on log file location and procedure to access it.
Tester has the necessary privileges to access the log files.
Execution Steps:
Execute the following steps:
  1. The tester tries to login to the webserver using the correct and incorrect login credentials.
  2. The tester verifies whether the login attempts were logged correctly with all of the required information.
Expected Results:
All webserver events are logged with all of the required information.
Expected format of evidence:
Testing report contains copies of the log file showing the captured information.
Up

4.2.5.3  HTTP User sessions  p. 56

Requirement Name:
User sessions
Requirement Description:
To protect user sessions the Network Product shall support the following session ID and session cookie requirements:
  1. The session ID shall uniquely identify the user and distinguish the session from all other active sessions.
  2. The session ID shall be unpredictable.
  3. The session ID shall not contain sensitive information in clear text (e.g. account number, social security, etc.).
  4. In addition to the Session Idle Timeout (see clause 4.2.3.5.2 Protecting sessions - Inactivity timeout), the Network Product shall automatically terminate sessions after a configurable maximum lifetime This maximum lifetime defines the maximum session span. When the maximum lifetime expires, the session shall be closed, the session ID shall be deleted and the user shall be forced to (re)authenticate in the web application and to establish a new session. The default value for this maximum lifetime shall be set to 8 hours.
  5. Session ID's shall be regenerated for each new session (e.g. each time a user logs in).
  6. The session ID shall not be reused or renewed in subsequent sessions.
  7. The Network Product shall not use persistent cookies to manage sessions but only session cookies. This means that neither the "expire" nor the "max-age" attribute shall be set in the cookies.
  8. Where session cookies are used the attribute 'HttpOnly' shall be set to true.
  9. Where session cookies are used the 'domain' attribute shall be set to ensure that the cookie can only be sent to the specified domain.
  10. Where session cookies are used the 'path' attribute shall be set to ensure that the cookie can only be sent to the specified directory or sub-directory.
  11. The Network Product shall not accept session identifiers from GET/POST variables.
  12. The Network Product shall be configured to only accept server generated session ID's.
Security Objective references:
tba.
Test case:
Purpose:
Verify that the above 12 session ID and session cookie requirements have been met.
Procedure and execution steps:
Pre-Conditions:
  • The Network Product uses a session ID that is communicated between the client and Network Product to establish and maintain a session.
  • Documentation describing how a session is maintained and where the session ID is stored / and how this is communicated and after how long sessions expire.
  • The documentation should describe the algorithm used to generate the session IDs.
Execution Steps:
  1. The tester logs in repeatedly with different user IDs and a number of times with the same user ID in a row and collects the session IDs according to the documentation and the user IDs associated with them. The tester verifies that:
    1. The session IDs are different between sessions of the same and different users;
    2. The session IDs seems random based on his/her own experience. The tester may use tests like the bitstream test or the count-the-1s-tests from the diehard test suite. The tester documents how randomness was verified;
    3. The session IDs are always different between sessions, also when the user ID is the same.
  2. The tester verifies that when session cookies are used
    1. neither the "expire" or the "max-age" is set;
    2. the 'HttpOnly' is set to true;
    3. the 'domain' attribute is set to the correct domain;
    4. the 'path' attribute is set to the correct directory or sub-directory.
  3. The tester verifies that it is impossible to:
    1. access a session by retrieving the session ID and communicating the session ID through a POST or GET variable.
    2. generate a session ID on the client by attempting to login with a custom generated session ID.
    3. keep a session alive for longer than the configured maximum lifetime (by default 8 hours).
Expected Results:
  1. A list of session IDs and user IDs that are different between sessions even when the tester has logged in with the same user and that are unpredictable as is confirmed by the entropy calculation.
  2. A confirmation from the tester that the correct variables are indeed set.
  3. A denied access to the tester when attempting the two login steps of step 3 and an expired session in step 3c.
Expected format of evidence:
A confirmation that the tester has confirmed that:
  1. Session IDs follow the rules 1-3, 5, 6.
  2. A session times out after 8 hours or sooner according to the documentation.
  3. The correct cookie settings are used.
  4. The network product does not accept customly generated session IDs and that session IDs over GET or POST are ignored.
Up

4.2.5.4  HTTP input validation  p. 58

Requirement Name:
Input validation
Requirement Description:
The Network Product shall have a mechanism in place to ensure that web application inputs are not vulnerable to command injection or cross-site scripting attacks. The Network Product shall validate, filter, escape, and encode user-controllable input before it is placed in output that is used as a web page that is served to other users.
Security Objective references:
tba.
Test case:
This requirement is covered by the basic vulnerability testing as described in clause 4.4.
Up

4.2.6  Network Devices  p. 58

4.2.6.1  Protection of Data and Information  p. 58

Refer to clause 4.2.3.2 for requirements on protection of data and information.

4.2.6.2  Protecting availability and integrity  p. 58

4.2.6.2.1  Packet filtering  p. 58
Requirement Name:
Packet filtering
Requirement Description:
The Network Product shall provide a mechanism to filter incoming IP packets on any IP interface (see RFC 3871 for further information).
In particular the Network Product shall provide a mechanism:
  1. To filter incoming IP packets on any IP interface at Network Layer .and Transport Layer of the stack ISO/OSI.
  2. To allow specified actions to be taken when a filter rule matches. In particular at least the following actions should be supported:
    • Discard/Drop: the matching message is discarded, no subsequent rules are applied and no answer is sent back.
    • Accept: the matching message is accepted.
    • Account: the matching message is accounted for i.e. a counter for the rule is incremented. This action can be combined with the previous ones. This feature is useful to monitor traffic before its blocking.
  3. To enable/disable for each rule the logging for Dropped packets, i.e. details on messages matching the rule for troubleshooting.
  4. To filter on the basis of the value(s) of any portion of the protocol header.
  5. To reset the accounting.
  6. The Network Product shall provide a mechanism to disable/enable each defined rule.
Security Objective references:
PROTECTED COMMUNICATIONS, HARDENING.
Test case:
Test Name:
TC_PACKET_FILTERING
Purpose:
Verify that the system provides functionality for incoming packet filtering
Procedure and execution steps:
Pre-Conditions:
  • The Network Product has packet filtering enabled.
  • The Network Product has 2 different logical or physical Ethernet ports and each port is connected to a host.
Execution Steps:
  1. The tester configures the Network Product to only allow ICMP traffic from host 1.
  2. The tester initiates ping traffic from host 1.
  3. The tester initiates ping traffic from host 2.
Expected Results:
Host 1 will receive a 'ping' answer back, but host 2 will not.
Expected format of evidence:
NA
Up
4.2.6.2.2  Interface robustness requirements  p. 59
Requirement Name:
Manipulated packets that are sent to an address of the network device shall not lead to an impairment of availability.
Requirement Description:
A network device shall be not affected in its availability or robustness by incoming packets, from other network element, that are manipulated or differing the norm. This means that appropriate packets shall be detected as invalid and be discarded. The process shall not be affecting the performance of the network device. This robustness shall be just as effective for a great mass of invalid packets as for individual or a small number of packets.
Examples of such packets are:
  • Mass-produced TCP packets with a set SYN flag to produce half-open TCP connections (SYN flooding attack).
  • Packets with the same IP sender address and IP recipient address (Land attack).
  • Mass-produced ICMP packets with the broadcast address of a network as target address (Smurf attack).
  • Fragmented IP packets with overlapping offset fields (Teardrop attack).
  • ICMP packets that are larger than the maximum permitted size (65,535 Bytes) of IPv4 packets (Ping-of-death attack).
  • Uncorrelated reply packets (i.e. packets which cannot be correlated to any request).
Sometimes the relevant behaviour of the network device will be configured. In other cases, the behaviour of the network device may only be verified by the relevant tests.
Security Objective references:
PROTECTED COMMUNICATIONS, HARDENING.
Test case:
Refer to Test Case in clause 4.4.4.
Up
4.2.6.2.3  GTP-C Filtering  p. 59
Requirement Name:
GTP-C Filtering
Requirement Description:
The following capability is conditionally required:
  • For each message of a GTP-C-based protocol, it shall be possible to check whether the sender of this message is authorized to send a message pertaining to this protocol.
  • At least the following actions should be supported when the check is satisfied:
  • Discard: the matching message is discarded.
  • Accept: the matching message is accepted.
  • Account: the matching message is accounted for, i.e. a counter for the rule is incremented. This action can be combined with the previous ones. This feature is useful to monitor traffic before its blocking.
This requirement is conditional in the following sense: It is required that at least one of the following two statements holds:
  • The Network Product supports the capability described above and this is stated in the product documentation.
  • The Network Product's product documentation states that the capability is not supported and that the Network Product needs to be deployed together with a separate entity which provides the capability described above.
Security Objective references:
tba.
Test case:
The test case described here apply only when GTP-C filtering is provided on the Network Product itself.
Test Name:
TC_GTP-C_FILTERING
Purpose:
To verify that the network product provides filtering functionalities for incoming GTP-C messages. In particular this test case verifies that:
  1. The network product provides filtering of incoming GTP-C messages on any interface.
  2. It is possible to block all GTP-C messages on those network product interfaces where they are unwanted.
  3. It is possible to specify defined actions for each rule.
Procedure and execution steps:
Pre-Conditions:
  • The network product has at least two physical interfaces, named if1 and if2.
  • The tester has the privileges to configure GTP-C filtering on the network product.
  • The manufacturer declares that the GTP-C filtering is supported.
  • The manufacturer includes a guideline to configure the GTP-C filtering in the documentation accompanying the network product.
  • A network traffic generator or a pcap file containing the GTP-C messages is available.
  • A network traffic analyser on the network product (e.g. tcpdump) is available.
Execution Steps:
  1. The tester log in the network product.
  2. The tester configures the network product with the following rules:
    1. Accept only GTP-C EchoRequest messages on if1.
    2. Discard all GTP-C messages on if2.
    3. For each rule above the accounting is also enabled.
  3. The tester turns on the network traffic analyser on if2.
  4. The tester sends on if2 EchoRequest messages replying a pcap file or using a network generator.
    1. Using the network analyser the tester verifies that the network product correctly receives the EchoRequest messages on if2.
    2. Using the accounting, the tester verifies that the messages are discarded and that any response is sent back by the network product.
  5. The tester sends to if1 EchoRequest messages replying a pcap file or using a network generator.
    1. Using the network analyser, the tester verifies that the messages are correctly received by the network product.
    2. The tester verifies that the GTP-C EchoRequest messages are not discarded because EchoResponse messages are sent back by the network product.
  6. The tester verifies that the matching messages are correctly accounted for both rules.
  7. The tester sends to if1 GTP-C messages different from EchoRequest replying a pcap file or using a network generator.
    1. Using the network analyser, the tester verifies that the messages are correctly received by the network product.
    2. Using the accounting, the tester verifies that the messages are discarded and that any response is sent back by the network product.
  8. The tester deletes the previous rules and configures a new rule, i.e. to accept only GTP-C EchoRequest on if1 coming from a certain IP Address named IP1.
  9. The tester sends GTP-C EchoRequest messages with source IP Address set to IP1:
    1. Using the network analyser, the tester verifies that the messages are correctly received by the network product.
    2. The tester verifies that the GTP-C EchoRequest messages are not discarded and EchoResponse messages are sent back by the network product.
  10. The tester sends GTP-C EchoRequest messages with source IP Address set to IP2 different from IP1 using a network traffic generator or replying a pcap file.
    1. Using the network analyser the tester verifies that the messages are correctly received by the network product.
    2. The tester verifies that the GTP-C EchoRequest messages are discarded and that no EchoResponse messages are sent back.
Expected Results:
  • For steps 4, 5, 6 and 7 the tester receives GTP-C EchoResponse messages from if1 only.
  • For steps 4, 5, 6 and 7 the messages matching the rules are correctly accounted.
  • For steps 8, 9, 10 the tester receives GTP-C EchoResponse messages only for the authorized source IP address.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
  • The used tool(s) name and version information
  • Settings and configurations used
  • Pcap trace
  • Screenshot
Test result (Passed or not)
Up
4.2.6.2.4  GTP-U Filtering  p. 62
Requirement Name:
GTP-U Filtering
Requirement Description:
The following capability is conditionally required:
  • For each message of a GTP-U-based protocol, it shall be possible to check whether the sender of this message is authorized to send a message pertaining to this protocol.
  • At least the following actions should be supported when the check is satisfied:
  • Discard: the matching message is discarded.
  • Accept: the matching message is accepted.
  • Account: the matching message is accounted for, i.e. a counter for the rule is incremented. This action can be combined with the previous ones. This feature is useful to monitor traffic before its blocking.
This requirement is conditional in the following sense: It is required that at least one of the following two statements holds:
  • The Network Product supports the capability described above and this is stated in the product documentation.
  • The Network Product's product documentation states that the capability is not supported and that the Network Product needs to be deployed together with a separate entity which provides the capability described above.
Security Objective references:
tba.
Test case:
The test case described here apply only when GTP-U filtering is provided on the Network Product itself.
Test Name:
TC_GTP-U_FILTERING
Purpose:
To verify that the network product provides filtering functionalities for incoming GTP-U messages. In particular this test case verifies that:
  1. The network product provides filtering of incoming GTP-U messages on any interface.
  2. It is possible to block all GTP-U messages on those network product interfaces where they are unwanted.
  3. It is possible to specify defined actions for each rule.
    Procedure and execution steps:
Pre-Conditions:
  • The network product has at leastone physical interface named if1 and may have another physical interface named if2 .
  • The tester has the privileges to configure GTP-U filtering on the network product.
  • The manufacturer declares that the GTP-U filtering is supported.
  • The manufacturer includes a guideline to configure the GTP-U filtering in the documentation accompanying the network product.
  • A network traffic generator or a pcap file containing the GTP-U messages is available.
  • A network traffic analyser on the network product (e.g. tcpdump) is available.
Execution Steps:
  1. The tester log in the network product.
  2. The tester configures the network product with the following rules:
    1. Accept only GTP-U EchoRequest messages on if1.
    2. Discard all GTP-U messages on if2.
    3. For each rule above the accounting is also enabled.
  3. The tester turns on the network traffic analyser on if2.
  4. The tester sends on if2 EchoRequest messages replying a pcap file or using a network generator.
    1. Using the network analyser the tester verifies that the network product correctly receives the EchoRequest messages on if2.
    2. Using the accounting, the tester verifies that the messages are discarded and that any response is sent back by the network product.
  5. The tester sends to if1 EchoRequest messages replying a pcap file or using a network generator.
    1. Using the network analyser, the tester verifies that the messages are correctly received by the network product.
    2. The tester verifies that the GTP-U EchoRequest messages are not discarded because EchoResponse messages are sent back by the network product.
  6. The tester verifies that the matching messages are correctly accounted for both rules.
  7. The tester sends to if1 GTP-U messages different from EchoRequest replying a pcap file or using a network generator.
    1. Using the network analyser, the tester verifies that the messages are correctly received by the network product.
    2. Using the accounting, the tester verifies that the messages are discarded and that any response is sent back by the network product.
  8. The tester deletes the previous rules and configures a new rule, i.e. to accept only GTP-U EchoRequest on if1 coming from a certain IP Address named IP1.
  9. The tester sends GTP-U EchoRequest messages with source IP Address set to IP1:
    1. Using the network analyser, the tester verifies that the messages are correctly received by the network product.
    2. The tester verifies that the GTP-U EchoRequest messages are not discarded and EchoResponse messages are sent back by the network product.
  10. The tester sends GTP-U EchoRequest messages with source IP Address set to IP2 different from IP1 using a network traffic generator or replying a pcap file.
    1. Using the network analyser the tester verifies that the messages are correctly received by the network product.
    2. The tester verifies that the GTP-U EchoRequest messages are discarded and that no EchoResponse messages are sent back.
Expected Results:
  • For steps 4, 5, 6 and 7 the tester receives GTP-U EchoResponse messages from if1 only.
  • For steps 4, 5, 6 and 7 the messages matching the rules are correctly accounted.
  • For steps 8, 9, 10 the tester receives GTP-U EchoResponse messages only for the authorized source IP address.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
  • The used tool(s) name and version information
  • Settings and configurations used
  • Pcap trace
  • Screenshot
Test result (Passed or not)
Up

Up   Top   ToC