Indian Telecom Security Assurance Requirements  
For 
IP Router  
 
 
 
 
 
 
 
 
 
 
 
 
 
Security Assurance Standards (SAS),  
National Center for  Communications Security, Bengaluru  
Department of Telecom, Ministry of Communications  
Government of India   
   
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 2 of 45 
© NCCS 2020  
 
Common Security Requirements  (CSR)  
Table of Contents  
Section 1: Access and Authorization  ................................ ................................ .............................  6 
1.1 Management Protocols Mutual Authentication  ................................ ................................ ........  6 
1.2 Management Traffic Protection  ................................ ................................ ...............................  6 
1.3 R ole-Based access control  ................................ ................................ ................................ ....... 6 
1.4 User Authentication – Local/Remote  ................................ ................................ .......................  7 
1.5 Remote login restrictions for privileged users  ................................ ................................ ..........  7 
1.6 Authorization Policy ................................ ................................ ................................ ................  7 
1.7 Unambiguous identification of the user & group accounts removal ................................ ..........  8 
Section 2: Auth entication Attribute Management  ................................ ................................ ..........  8 
2.1 Authentication Policy  ................................ ................................ ................................ ..............  8 
2.2 Authentication Support – External  ................................ ................................ ...........................  9 
2.3 Protection against brute force and dictionary attacks  ................................ ................................  9 
2.4 Enforce Strong Password  ................................ ................................ ................................ ....... 10 
2.5 Inactive Session Timeout  ................................ ................................ ................................ ....... 11 
2.6 Password Changes  ................................ ................................ ................................ .................  11 
2.7 Protected  Authentication feedback ................................ ................................ ........................  12 
2.8 Removal of predefined or default authentication attributes  ................................ ....................  13 
Section 3: Software Security  ................................ ................................ ................................ ....... 13 
3.1 Secure Update  ................................ ................................ ................................ .......................  13 
3.2 Secure Upgrade  ................................ ................................ ................................ .....................  14 
3.3 Source code security assurance  ................................ ................................ ..............................  14 
3.4 Known Malware Check  ................................ ................................ ................................ .........  15 
3.5 No unused software  ................................ ................................ ................................ ...............  15 
3.6 Unnecessary Service Removal  ................................ ................................ ...............................  15 
3.7 Restricting System Boot Sou rce ................................ ................................ ............................  16 
3.8 Secure Time Synchronization  ................................ ................................ ................................  16 
3.9 Self Testing  ................................ ................................ ................................ ...........................  16 
3.10 Restricted reachabili ty of services ................................ ................................ ........................  17 
3.11 Avoidance of Unspecified Wireless Access  ................................ ................................ .........  17 
Section 4: System Secure Execution Environment  ................................ ................................ ....... 17 
4.1 No unused functions  ................................ ................................ ................................ ..............  17 
4.2 No unsupported components  ................................ ................................ ................................ . 18 
Section 5: User Audit  ................................ ................................ ................................ ..................  18 
5.1 Audit trail storage and protection  ................................ ................................ ...........................  18 
5.2 Audit Event Generation  ................................ ................................ ................................ .........  18 
5.3 Secure Log Export  ................................ ................................ ................................ .................  24 
Section 6: Data Protection  ................................ ................................ ................................ ...........  26 
6.1 Cryptographic Based Secure Communication  ................................ ................................ ........  26 
6.2 Cryptographic Key Generation  ................................ ................................ ..............................  28 
6.3 Cryptographic Key Destruction  ................................ ................................ .............................  28    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 3 of 45 
© NCCS 2020  
 
6.4 Cryptographic Key Establishment  ................................ ................................ .........................  29 
6.5 Protecting data and information – Confidential System Internal Data  ................................ .... 29 
6.6 Protecting data and information in storage  ................................ ................................ .............  30 
6.7. Protection  again st  copy of  data……  ………………………………………………………30  
6.8. Protection against Data Exfiltration - Over Channel……… ….…………………………….31  
Section 7: Network Services ................................ ................................ ................................ ........  31 
7.1 Traffic Filtering – Network Level  ................................ ................................ ..........................  31 
7.2 Traffic Separation  ................................ ................................ ................................ ..................  33 
7.3 Traffic Protection –Anti-Spoofing  ................................ ................................ .........................  33 
Section 8: Attack Prevention Mechanisms  ................................ ................................ ...................  33 
8.1 Network Level and application level DDoS  ................................ ................................ ...........  33 
8.2 Excessive Overload Protection  ................................ ................................ ..............................  34 
8.3 Filtering IP Options  ................................ ................................ ................................ ...............  34 
Section 9: Vulnerability Testing Requirements  ................................ ................................ ............  35 
9.1 Fuzzing – Network and Application Level  ................................ ................................ .............  35 
9.2 Port Scanning  ................................ ................................ ................................ ........................  35 
9.3 Vulnerability Scanning  ................................ ................................ ................................ ..........  35 
Section 10: Operating System  ................................ ................................ ................................ ..... 36 
10.1 Growing Content Handling  ................................ ................................ ................................ .. 36 
10.2 Handling of ICMP  ................................ ................................ ................................ ...............  36 
10.3 Authenticated Privilege Escalation only  ................................ ................................ ...............  37 
10.4 System account identification  ................................ ................................ ..............................  38 
10.5 OS Hardening - Kernel Security  ................................ ................................ ..........................  38 
10.6 No automatic launch of removable media  ................................ ................................ ............  39 
Section 11: Web Servers  ................................ ................................ ................................ .............  40 
11.1 HTTPS  ................................ ................................ ................................ ................................  40 
11.2 Webserver logging  ................................ ................................ ................................ ..............  40 
11.3 HTTP User sessions  ................................ ................................ ................................ ............  41 
11.4 HTTP input validation  ................................ ................................ ................................ .........  42 
11.5 No system privileges  ................................ ................................ ................................ ...........  42 
11.6 No unused HTTP methods  ................................ ................................ ................................ ... 42 
11.7 No unused add -ons ................................ ................................ ................................ ..............  42 
11.8 No compiler, interpreter, or shell via CGI or other server -side scripting  ...............................  43 
11.9 No CGI or other scripting for uploads  ................................ ................................ ..................  43 
11.10 No execution of system commands with SSI  ................................ ................................ ..... 43 
11.11 Access rights for web server configuration  ................................ ................................ ........  43 
11.12 No default content  ................................ ................................ ................................ .............  43 
11.13 No directory listings  ................................ ................................ ................................ ..........  44 
11.14 Web server information in HTTP headers  ................................ ................................ ..........  44 
11.15 Web server information in error pages  ................................ ................................ ...............  44 
11.16 Minimized file type mappings  ................................ ................................ ...........................  44 
11.17 Restricted file access  ................................ ................................ ................................ .........  44 
11.18 Execute rights exclusive for CGI/Scripting directory  ................................ .........................  44    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 4 of 45 
© NCCS 2020  
 
Section 12: Other Security requirements ................................ ................................ ......................  45 
12.1 Remote Diagnostic Procedure – Verification  ................................ ................................ ....... 45 
12.2 No Password Recovery  ................................ ................................ ................................ ........  45 
12.3 Secure System Software Revocation  ................................ ................................ ....................  45 
12.4 Software Integrity Check – Installation  ................................ ................................ ................  46 
12.5 Software Integrity Check – Boot ................................ ................................ ..........................  46 
12.6 Unused Physical Interfaces Disabling  ................................ ................................ ..................  46 
12.7 No Default Profile  ................................ ................................ ................................ ...............  46 
12.8. Security Algorithm Modification  ................................ ................................ .........................  46 
12.9.  Control Plane Traffic Protection  ................................ ................................ .........................  47 
ABBREVIATIONS  ................................ ................................ ................................ ....................  48 
 
 
 
Section 1: Access and Authorization  
1.1 Management Protocols Mutual Authentication  
 
Requirement:   
 
The protoc ols used for the Network Product’ s  management shall support mutual 
authentication mechanisms.  
There is mutual authentication of entities for management interfaces on the network 
product.    
HTTPS with TLS 1.2 , SNMP V3  Protocols are allowed  
 [Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.2.3.4.4.1]  
1.2 Management Traffic Protection  
 
Requirement:  
 
(a)  Usage of cryptographically protected network protocols is required. The 
transmission of data with a need of protection shall use industry standard network 
protocols with sufficient security measures and industry accepted algorithms. In    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 5 of 45 
© NCCS 2020  
 
particular, a protocol version without known vulnerabilities or a secure alternative shall 
be used.Verify the mechanisms implemented to protect data and information in transfer 
to and from the Network Product's OAM interface.  
 
 [Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0   Section  4.2.3.2.4]  
 
1.3 Role -Based access control  
Requirement:  
    
The network product shall support Role Based Access Control (RBAC). A role -based 
access control system uses a set of controls which determines how users interact with 
domains and resources. The domains could be Fault Management (FM), Performance 
Management (PM), System Admin, etc. The RBAC system controls how  users or 
groups of users are allowed access to the various domains and what type of operation 
they can perform, i.e. the specific operation command  or command group (e.g. View, 
Modify, Execute).  
 
The network product supports RBAC with minimum  of  3 user roles , in particular, for 
OAM privilege management for network product Management and Maintenance, 
including authorization of the operation for configuration data and software via the 
network product console interface  
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . Section 4.2.3.4.6.2]  
1.4 User Authentication – Local/Remote  
Requirement:     
 
The various  user and machine  accounts  on a system  shall be protected  from misuse.  
To this end, an authentication  attribut e is typicall y used , which , when combine d with the 
user name , enable s unambiguou s authenticatio n and identi fication  of the authorized  
user.  
Authentication  attributes  include:  
 
- Cryptographic  keys 
- Token  
- Passwords     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 6 of 45 
© NCCS 2020  
 
This means that authentication based on a parameter that can be spoofed (e.g. phone 
numbers, public IP addresses or VPN membership) is not permitted. Exceptions are 
attributes that cannot be faked or spoofed by an attacker.  
 
NOTE:  Several  of the above op tions  can be combined  (dual -factor  authentication)  
to achieve  a higher level of  security.  Whether  or not  this is suitable  and necessary  
depends  on the protection  needs of  the individual  system  and its data and  is evaluated  
for individual  cases.  [Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . 
Section 4.2.3.4.2.1]  
 
1.5 Remote login restrictions for privileged users  
Requirement:  
 
Direct login as root or equivalent highest privileged user shall be limited to the system 
console only. Root user will not be allowed to login to the system remotely.  
 
[Reference  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . Section 4.3.2.6]  
 
 
1.6 Authorization Policy  
Requirement:  
 
The authorizations for accounts and applications shall be reduced to the minimum 
required for the tasks they have to perform.  
 
Authorizations to a system shall be restricted to a level in which a user can only access 
data and use functions that he needs in the course of his work. Suitable authorizations 
shall also be assigned for access to files that are components of the operating system 
or of applications or that are generated by the same (e.g. configuration a nd logging 
files).  
 
Alongside access to data, execution of applications and components shall also take 
place with righ ts that are as low as possible. Applications should not be executed with 
administrator or system rights.  
 
 
[Reference:  TSDSI STD T1.3GPP 3 3.117 -14.2.0 V.1.0.0  . Section 4.2.3.4.6.1]     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 7 of 45 
© NCCS 2020  
 
 
1.7    Unambiguous identification of the user & group accounts 
removal  
Requirement:  
 
Users shall be identified unambiguously by the   Router . Router  shall support 
assignment of individual accounts per user, where a user could be a person, or, for 
Machine Accounts, an application, or a system. Router  shall not enable the use of 
group accounts or group credentials, or sharing of the sa me account between several 
users, by default.  
 
 [Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0  . Sections  4.2.3.4.1.2]  
 
Section 2: Authentication Attribute Management  
2.1 Authentication Policy  
Requirement:  
 
The usag e of a syste m function  without successful authentication on basis of the user 
identity and at least one authentication attribute (e.g. password, certificate) shall be 
prevented. System functions comprise, for example networ k service s (like SSH, SFTP , 
Web services) , local acces s via a managemen t console , local usag e of operating 
system and applications.  
 
 
This requirement shall also be applied to accounts that are only used for communication 
between systems. An exception to the authentication and authorization requirement are 
functions for public use  such  as those for a  Web server on the Internet, via which 
informatio n is made availabl e to the public . 
 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0.  Section 4.2.3.4.1.1]   
 
2.2 Authentication Support – External  
Requirement:  
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 8 of 45 
© NCCS 2020  
 
External authentication mechanism if supported by Network product (support 
authentication, authorisation and accounting server capabilities) should be through 
secure (encrypted) communication channel.  
2.3 Protection against brute force and dictionary attacks  
Requirement:  
 
If a password is used as an authentication attribute, a protection against brute force and 
dictionary attacks that hinder password guessing shall be implemented.  Brute force and 
dictionary attacks aim to use automated guessing to ascertain passwords for user and 
machine accounts. Various measures or a combination of these measures can be taken 
to prevent this.  The most commonly used protection measures are:  (i) Using the timer 
delay (this delay could be the same or increased depending the operator's policy for 
each attempt) for each newly entered password  input following a n incorrect entry ("tar 
pit").(ii)Blocking an account following a specified number of incorrect attempts,.  
However it has to be taken i nto account that this solution needs a process for unlocking 
and an attacker can force this to deactivate accounts and make them unusable. 
(iii)Using CAPTCHA to prevent automated attempts (often used for Web appli cations). 
(iv) Using a password blacklist t o prevent vulnerable passwords.  
 
In order to achieve higher security, it is often meaningful  to combine two or more of the 
measures named here. It is left to the vendor to select appropriate measures.  
Above requirements shall be applicable for all passwo rds used (e.g. application -level, 
OS-level, etc.). An exception to this requirement is machine accounts.  
 
NOTE 1: Password management and blacklist configuration may be done in a separate 
node that is different to the node under test, e.g. a SSO server or any other central 
credential manager.  
 
 [Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . Section 4.2.3.4.3.3]  
 
 
2.4 Enforce Strong Password  
Requirement:  
 
(a) The setting by the vendor shall be such that a network product shall only accept 
passwords that comply with the following complexity criteria:  
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 9 of 45 
© NCCS 2020  
 
(i)Absolute minimum length of 8 characters (shorter lengths shall be rejected by the 
network product). It shall not be possible setting this absolute minimum length to a lower 
value by configur ation.  
(ii)Comprising at least three of the following categories:  
- at least 1 uppercase character (A -Z)  
- at least 1 lowercase character (a -z)  
- at least 1 digit (0 -9)  
- at least 1 special character (e.g. @;!$.)  
 The minimum length of characters in t he passwords and the set of allowable special 
characters shall be configurable by the operator. The default minimum length is the 
value configured by the vendor before any operator -specific configuration has been 
applied. The special characters may be cate gorized in sets according to their Unicode 
category.  
 
If a central system is used for user authentication password policy is performed on the 
central system and additional assurance shall be provided that the central system 
enforces the same password compl exity rules as laid down for the local system in this 
subclause. If a central system is not used for user authentication, the assurance on 
password complexity rules shall be performed on the Network Product.  
 
When a user is changing a password or entering a new password the system checks 
and ensures that it meets the password requirements. Above requirements shall be 
applicable for all passwords used (e.g. application -level, OS -level, etc.).  
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0   Section 4.2.3.4.3  
2.5 Inactive Session Timeout  
Requirement:  
 
(a) An  OAM user interactive sessio n shall be terminate d automaticall y after a specifie d 
period  of inactivity . It shall be possible to configure an inactivity time -out period.  
 
NOTE : The kind of activity required to reset the timeout timer depends on the type of      
user session.   
 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .Section 4.2.3.5.2]  
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 10 of 45 
© NCCS 2020  
 
2.6 Password Changes  
Requirement:  
 
If a password is used as an authentication attribute, then the  system shall offer a 
function that enables a user to change his password at any time. When an external 
centralized system for user authentication is used it is possible to redirect or implement 
this function on this system.  
 
Password change shall be enforced after initial login.  
 
The system shall enforce password change based on password management policy. In 
particular, the system shall enforce password expiry.  
 
Previously used passwords shall not be allowed up to a certain number (Password 
History).  
 
The number of disallowed previously used passwords shall be:  
 
• Configurable;  
• Greater than 0;  
• And its default value sha ll be 3.  This means that the Network product  shall store 
at least the three previously set passwords. The maximum number of passwords 
that the network product can store for each user is up to the manufacturer.  
 
When a password is about to expire a password expiry notification shall be provided to 
the user . Above requirements shall be applicable for all passwords used(e.g. 
application -level, OS -level, etc.). An exception to this requirement is machine accounts.  
 
This require ment shall  be met either by Network product   itself or in combination with 
external authentication system .  
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . Section 4.2.3.4.3.2]  
 
 
2.7 Protected Authentication feedback  
Requirement:  
 
(a) The Authentication attribute s  shall not be displayed in such a way that it could be 
seen and misused by a casual local observer. Typically, the individual characters of    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 11 of 45 
© NCCS 2020  
 
the password are replaced by a character such as "*". Under certain circumstances 
it may be permissible for an indivi dual character to be displayed briefly during input. 
Such a function is used, for ex ample, on smartphones to make input easier. 
However, the entire password is never output to the display in plaintext.  
 
Above requirements shall be applic able for all authentication attributes  used(e.g. 
application -level, OS-level, etc.). An exception to this requirement is machine 
accounts  
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .  Section 
4.2.3.4.3.4 ]  
  
2.8 Removal of predefined or default authentication attributes  
Requirement:       
 
Predefined  or default authentication  attributes  shall be deleted  or disabled.  
 
Normally,  authentication attributes  such  as password  or cryptographic keys  will be 
preconfigured from  producer, vendor  or developer  of a system.  Such  authentication  
attributes  shall be changed  by automatically forcing a user to change it on 1st time login 
to the system or the vendor provides instructions on how to manually change it.  
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . Section 5.2.3.4.2.3 ] 
 
Section 3: Software Security  
3.1 Secure Update   
Requirement:  
 
Network product’s  system software updates should be secure and shall be based on 
signed certificates. Network product shall allow updates only if code signing certificate is 
valid and time not expired, the software update integrity shall be verified by ha shing 
mechanism (like SHA2).  
  
 
Note :  TSP’s are responsible to ensure that Software updates/patches implemented are 
secure and safe from any vulnerability.  TSP’s to maintain information about updates as    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 12 of 45 
© NCCS 2020  
 
per Licensing agreement /amendment conditions . However if there is any 
patch/update/version change which affects the security functionality then the details of 
the same should be reported to  TTSC/DOT by vend or /TSP’s  
 
3.2 Secure Upgrade  
Requirement:  
 
(i) Software package integrity shall be validated in the installation/upgrade stage.  
(ii) Network product shall support software package integrity validation via cryptographic 
means, e.g. digital signature. To this end, the network product has a list of public keys 
or certificates of authorised software sources, and uses the keys to verify  that the 
software update is originated from only these sources.  
(iii) Tampered software shall not be executed or installed if integrity check fails.  
(iv) A  security mechanism is required to guarantee that only authorized individuals can 
initiate and deploy a software update, and modif y the list mentioned in bullet 2  
 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . Section 4.2.3.3.5]  
3.3 Source code security assurance  
Requirement:  
 
Vendor shall ensure the following while developing Network product’s OS /Application 
Software                
 
(i) Industry standard best practices of secure coding  during the entire software 
development life cycle of the Network product Software, which includes vendor 
developed code, third party software and open source code li braries used/embedded  in 
the Network product   
 
(ii)The Network product software is free from known security vulnerabil ities, security 
weaknesses listed in the CWE database  and  all the exploitable security  vulnerabilities 
listed in the late st SANS Top 25 and OWASP Top 10  
 
(iii) The binary file for Network product  application is generated from the source code 
that is fr ee from all the stated coding secu rity vul nerabilities stated in  (ii)  
 
Vendor shall submit  Software  Test Document ( STD)  to  lab for  scrutiny     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 13 of 45 
© NCCS 2020  
 
 
3.4 Known Malware Check  
 
Requirement:  
 
Vendor  shall submit Software  Test Document ( STD)   of the network product proving  
that  the network product  is free from  known malware/spyware  to lab for scrutiny  
 
 
3.5 No unused software  
Requirement:  
 
Unused software components or parts of software which are not needed for operation or 
functionality of the Network product  shall not be installed or shall be deleted after 
installation. This includes also parts of a software, which will be installed as examples 
but typically not be used (e.g. default web pages, example databas es, test data).  
 
Note : Vendor shall provide the list of software that are necessary for its operation.  
 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .  Section 4.3.2.3]  
3.6 Unnecessary Service Removal  
Requirement:  
 
The Network product  shall only run protocol handlers and services which are needed 
for its operation, and which do not have any known security vulnerabilities. In particular, 
by default the following services shall be initially con figured to be disabled o n the 
Network product  by the vendor.  
 
- FTP 
- TFTP  
- Telnet  
- rlogin, RCP, RSH  
- HTTP  
- SNMPv1 and v2     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 14 of 45 
© NCCS 2020  
 
- SSHv1  
- TCP/UDP Small Servers (Echo, Chargen, Discard and Daytime)  
- Finger  
- BOOTP server  
- Discovery protocols (CDP, LLDP)  
- IP Identification Service (Identd)  
- PAD 
- MOP  
 
NOTE 1:As an alternative to disabling the HTTP service, it is also possible for this 
service to remain active for reasons of user friendliness. In this case, however, queries 
to the web service may no t be answer ed directly on this port but from a redirected to 
HTTPS service.  
 
NOTE 2 : Full documentation of required pr otocols and servic es of the Network product 
and their purpose needs to be provided by the vendor as prerequisite for the test case.  
 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0.  Section 4.3.2.1]  
 
3.7 Restricting System Boot Source  
Requirement:  
 
The network product  can boot only from the memory devices intended for this purpose.  
The network product can only boot from memory devices intended for this purpose  (e.g. 
not fro m external memory like USB key)  
 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .  Section 4.2.3.3.2]  
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 15 of 45 
© NCCS 2020  
 
 
 
3.8 Secure Time Synchronization  
 
Requirement:  
 
Network Product shall provide reliable time and date information provided  manually by 
itself or through NTP server. Network product should generates audit logs for all 
changes to time settings. Network product should support to configure authentication 
between itself and external NTP server  
 
3.9 Self Testing  
Requirement:  
 
Network  product  shall perform self -tests to identify failures in  its security  
Mechanisms  during i)power on ii)  when  Administrator Instructs . (eg.,  integrity of the 
firmware and software as well as for the correct operation of cryptographic functions, 
etc.,)  
3.10 Restricted reachability of services  
Requirement:        
 
 
The network product shall restrict the reachability of services so that they can only be 
reached on interfaces where their usage is required. On interfaces were services are 
active, the reachability should be limited to legitimate commu nication peers. This 
limitation shall be realized on the network product itself.  
 
EXAMPLE: Administrative services (e.g. SSH, HTTPS, RDP) shall be restricted to 
interfaces in the management network to support separation of manage ment traffic from 
user traffic.  
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0   Section   4.3.2.2]  
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 16 of 45 
© NCCS 2020  
 
 
3.11 Avoidance of Unspecified Wireless Access  
Requirement:  
 
An undertaking sh all be given as follows: "The Network product  does not contain any 
wireless, optical, magnetic or any other component that may be used as a covert 
channel"  
 
Note: Network product  supporting standard wireless technologies would also need to 
be tested for this requirement apart from wireless technology related tests.  
 
Section 4: System Secure Execution Environment  
4.1 No unused functions  
Requirement:  
 
Unused functions of the Network product s' software and hardware shall be deactivated.  
 
During installation of software and hardware often functions will be activated that are not 
required for operation or function of the system. If unused functions of soft ware cannot 
be deleted or de -installed individually as given under requirement "3.9 No unused 
software " of this document, such functions shall be deactivated  in the configuration of 
the Network product permanently.  
 
Also hardware functions which are not required for operation or function of the system 
(e.g. unused interfaces) shall be permanently deactivated. Permanently means that they 
shall n ot be reactivated again after Network product  reboot.  
 
Example:  A debugging function in software which can be used for troubleshooting shall 
not be activated during normal operation of th e Network product  
 
Note: List  of the used functions of the Networks s software and hardware as given by 
the vendor shall match the list of used  software and hardware  functions that are 
necess ary for the operation of the Network product.  
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . Section 4.3.2.4]  
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 17 of 45 
© NCCS 2020  
 
4.2 No unsupported components  
Requirement:  
 
The Network product shall not contain software and hardware components that are no 
longer supported by their vendor, producer or developer, such as components that have 
reached end -of-life or end -of-support. Excluded are components that have a special 
supp ort contract. This contract shall guarantee the correction of vulnerabilities over 
components' lifetime.  
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0  . Section 4.3.2.5]  
 
Section 5: User Audit  
5.1 Audit trail storage and protection  
Requirement:  
 
(a)The security event log shall be access controlled (file access rights) , so only privilege 
users have  access to read  the log files but not allowed to delete the log files . This 
requirement  is applicable also applicable to  Administrator   
 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 . V.1.0.0   section 4.2.3.6.3]  
 
 
5.2 Audit Event Generation   
Requirement:  
 
The Network product  shall log all important Security events with unique System 
Reference such as IP Address, MAC address, hostname, etc. It shall be possible to log 
the events as g iven in the Table below. The Network product  shall record within each 
audit record at least in formation pertaining to Date and time of the event, type of event, 
subject identity, and the outcome (success or failure) of the event. Additional audit 
record information, depending on the audit event, shall also be provi ded as given in the 
Table below  
 
EventTypes ( Mandato
ry or optional )      Description   Event data to be logged  
Incorrect login Records any user incorrect login • Username,     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 18 of 45 
© NCCS 2020  
 
attempts ( Mandatory)  attempts to the DUT  • Source (IP address) if remote 
access  
Outcome of event (Success or 
failure)  
• Timestamp  
Administrator 
access ( Mandatory)  Records any access attempts to 
accounts that have system 
privileges.  • Username,  
• Timestamp,  
• Length of session,  
Outcome of event (Success or 
failure)  
• Source (IP address) if remote 
access  
Account 
administration ( Mandat
ory) Records all account 
administration activity, i.e. 
configure, delete, enable, and 
disable.  • Administrator username,  
• Administered account,  
• Activity performed (configure, 
delete, enable and disable)  
Outcome of event (Success or 
failure)  
• Timestamp  
Resource Usage  
( Mandatory)  Records events that have been 
triggered when system 
parameter values such as disk 
space, CPU load over a longer 
period have exceeded their 
defined thresholds.  • Value exceeded,  
• Value reached  
(Here suitable threshold values shall 
be defined depending on the 
individual system.)  
Outcome of event (Success or 
failure)  
• Timestamp  
Configuration 
change ( Mandatory)  Changes to configuration of the 
network device  • Change made  
* Timestamp  
Outcome of event (Success or 
failure)  
• Username  
Reboot/shutdown/crash
( Mandatory)  This event records any action on 
the network device that forces a 
reboot or shutdown OR where 
the network device has crashed.  • Action performed (reboot, shutdown, 
etc.)  
• Username (for intentional actions)  
Outcome of event (Success or    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 19 of 45 
© NCCS 2020  
 
failure)  
• Timestamp  
Interface status 
change (Mandatory)  Change to the status of 
interfaces on the network device 
(e.g. shutdown)  • Interface name and type  
• Status (shutdown, missing link, etc.)  
Outcome of event (Success or 
failure)  
• Timestamp  
Change of group 
membership or 
accounts  ( Option al) Any change of group 
membership for accounts  • Administrator username,  
• Administered account,  
• Activity performed (group added or 
removed)  
Outcome of event (Success or failure)  
• Timestamp.  
Resetting Passwords  
( Optional ) Resetting of user account 
passwords by the Administrator  • Administrator username,  
• Administered account,  
• Activity performed (configure, 
delete, enable and disable)  
Outcome of event (Success or 
failure)  
• Timestamp  
Services  ( Optional ) Starting and Stopping of 
Services (if applicable)  Service identity  
Activity performed (start, stop, etc.)  
Timestamp       
Outcome of event (Success or 
failure)  
User login  ( Mandatory)  All use of identification and 
authentication mechanism  user identity  
origin of attempt ( e.g.IP address)  
Timestamp       
outcome of event (Success or failure)  
X.509 Certificate 
Validation  ( Optional)  Unsuccessful attempt to validate 
a certificate  Timestamp       
Reason for failure  
Subject identity  
Type of event  
Secure Update  
( Optional ) attempt to initiate manual 
update, initiation of update, user identity  
Timestamp          
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 20 of 45 
© NCCS 2020  
 
completion of update  Outcome of event (Success or 
failure)  
Activity performed  
Time change ( optional ) Change in time settings  old value of time  
new value of time  
Timestamp       
origin of attempt to change time 
(e.g.IP address)  
Subject identity  
outcome of event (Success or failure)  
user identity  
Session unlocking/ 
termination  ( Optional ) Any attempts at unlocking of an 
interactive session, Termination 
of a remote session by the 
session locking mechanism, 
Termination of an  
interactive session  user identity (wherever applicable)  
Timestamp       
Outcome of event (Success or failure)  
Subject identity  
Activity performed  
Type of event  
Trusted 
Communication 
paths(with IT entities 
such as Authentication 
Server, Audit Server, 
NTP Server, etc. and 
for authorised remote 
administrators)  
( Optional)  Initiation, Termination and 
Failure of trusted 
Communication paths  Timestamp       
Initiator identity (as applicable)  
Target identity (as applicable)  
User identity (in case of Remote 
administrator access)  
Type of event  
Outcome of event (Success or failure, 
as applicable)  
Audit data 
changes ( Optional ) Changes to audit data including 
deletion of audit data  Timestamp       
Type of event (audit data deletion, 
audit data modification)  
Outcome of event (Success or failure, 
as applicable)  
Subject identity  
user identity  
origin of attempt to change time 
(e.g.IP address)  
Details of data deleted or modified     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 21 of 45 
© NCCS 2020  
 
 
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .Section 4.2.3.6.1]  
 
5.3 Secure Log Export   
Requirement:  
 
(I) (a) The Network Product shall support forward of security event logging data to an 
external system.  
(b) Log functions should support secure uploading of log files to a central location or to 
a system external for the Network Product that is logging  
[Refer ence:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0  . Section 4.2.3.6.2]  
 
Network product shall be able to store generated audit data itself may be wi th 
limitations.   
 
In the absence of  External system, Network product shall  support facility to drop new 
audit data or overwrite old audit data based on defined criteria in case of its own log 
buffer full  
 
Network product shall alert administrator when  its  log buffer rea ches configured  
threshold limit .  
 
Section 6: Data Protection  
6.1 Cryptographic Based Secure Communication  
Requirements:  
 
Requirements:  
 
Secure commun ication mechanism between the Network product  and the connected 
entities shall use only the industry standard and NIST recommended cryptographic 
protocols  such as IPSEC, VPN, SSH, TLS/SSL, etc. Also Network product  shall pro vide 
all cryptographic service  such as encryption , decryption, key exchange  ,  
authentication ,  data integrity etc using the   industry accepted and NIST recommended 
cryptographic algorithms ( with standard key lengths) such as SHA, Diffie -Hellman, 
AES , RSA etc.      
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 22 of 45 
© NCCS 2020  
 
 
 
6.2 Cryptographic Module Security Assurance  
An undertaking shall be provided by the vendor as below:  
 
      Cryptographic  module  embedded inside the Network product  (which may be in the 
form of hardware, software or firmware) that provides  all the  necessary security 
services such as authentication, integrity and confidentiality are designed and 
implemented in compliance with FIPS 140 -2 standards for different levels of security  
 
 
6.3. Cryptographic Algorithms implementation Security Assurance  
An un dertaking shall be provided by the vendor as below:  
  
 An undertaking shall be pr ovided by the vendor as below:  Cryptographic algorithms 
embedded in the crypto module of Network product are implemented in compliance with 
respective FIPS standards (for the specific crypto algorithm).  
             
6.4. Protecting data and information – Confidential System 
Internal Da ta 
Requirement:   
 
(a)When Network product  is in normal operational mode (i.e., not in maintenance 
mode) there shall be no system function that reveals confidential system internal data in 
the clear to users and administrators. Such system functions could be, for example, 
local or remote OAM CLI or GUI, error messages, logging messages, alarms, 
configuration file exports etc. Confidential system internal data contains authentication 
data (i.e. PINs, cryptographic keys, passwords, cookies) as  well as system internal data 
that is not required for systems administration and could be of advantage to attackers 
(i.e. stack traces in error m essages) . 
 
Access to maintenance mode should be restricted only to  authorised privileged user  
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . Section 4.2.3.2.2]     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 23 of 45 
© NCCS 2020  
 
6.5. Protecting data and information in storage  
 
Requirement  :     
 
For sensitive data in (persistent or temporary) storage read access rights shall be restricted. 
Files of a system that are needed for the functionality shall be protected against 
manipulation.  
 
In addition, the following rules apply for:  
 
(i)Systems that need access to identification and authentication data in the clear, e.g. in 
order to perform an authentication. Such systems shall not store this data in the clear, 
but scramble or encrypt it by implementation -specific means.  
(ii)Systems that do not need access to sensitive data (e.g. user passwords) in the clear. 
Such systems shall hash this sensiti ve data .  
(iii)Stored files: examples for protection against manipulation are  the use of check sum 
or cryptographi c method s. 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0  Section 4.2.3.2.3]  
6.6. Protection against Copy of Data  
Network product  shall have protection against creating a copy of data in use / data in 
transit. Protective measure should exists against  use of  available system func tions / 
software residing in Network product  to create copy of  data for illegal transmission.  The 
software functions, components in the Network product  for creation of data copy are to 
be disabled or sufficiently secured to prevent illegal copy of data.  
 
 
6.7. Protection against Data Exfiltration - Overt Channel  
Network product  shall have mechanisms to prevent data exfiltration attacks for theft of 
data in use / data in transit. Establishment of outbound overt channels  such as FTP, 
HTTP, HTTPS IM, P2P, Email etc are to be forbidden if they are initiated by / originate 
from t he Network product . Outbound -use of such servic es are to be disabled in the 
Network product , if it is essential to have some of these services for outbound -use 
(remote management etc.,), facility to exist for monitoring anomalous channels.  
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 24 of 45 
© NCCS 2020  
 
Section 7: Netwo rk Services  
7.1 Traffic Filtering – Network Level  
Requirement:  
 
(a) The Network product  shall provide a mechanism to filter incoming IP packets on any 
IP interface  
 
In particular the Network product shall provide a mechanism:  
 
(i) To filter incoming IP packets on any IP interface at Network Layer and Transport 
Layer of the stack ISO/OSI.  
(ii) 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 one s. This 
feature is useful to monitor traffic before its blocking.  
(iii) To enable/disable for each rule the logging for Dropped packets, i.e. details on 
messages matching the rule for troubleshooting.  
(iv)  To filter on the basis of the value(s) of any portion o f the protocol header.  
(v)   To reset the accounting.  
(vi)  The Network product  shall provide a mechanism to disable/enable each defined 
rule. 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .  section 4.2.6.2.1]  
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 25 of 45 
© NCCS 2020  
 
 
7.2 Traffic Separation  
Requirement:  
 
The Network product shall support physical or logical separation of O&M and control 
plane traffic. See RFC 3871 [3] for further information  
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.3.5.1]  
 
7.3 Traffic Protection –Anti-Spoofing  
Requirement:  
 
Systems shall not process IP packets if their source address is not reachable via the 
incoming interface. Implementation example: Use of "Reverse Path Filter" (RPF) 
provides this function.  
 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.3.3.1.1]  
 
Section 8: Attack Prevention Mechanisms  
8.1 Network Level and application level DDoS  
Requirement:  
 
The system  shall provide  security  measures  to deal with overload  situations which may 
occur as a result of a denial of service attack or during periods of increased traffic.  In 
particular,  partial  or complete  impairment of  system  availability  shall be avoided.  
Potential  protective  measures  include:  
 
- Restricting  of available  RAM  per application  
- Restricting  of maximum  sessions  for a Web application  
- Defining  the maximum  size of a dataset  
- Restricting  CPU resources  per process  
- Prioritizing  processes     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 26 of 45 
© NCCS 2020  
 
- Limiting  of amount  or size of transactions  of an user or from an IP address  in a 
specific  time range  
Note :  Network product should have protection  mechanism  against  known network 
level and Application DDoS attacks   
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.2.3.3.1]  
 
 
8.2 Excessive Overload Protection  
Requirement:  
 
 The system shall act in a predictable way if an overload situation cannot be prevented.  
A system shall be built in this way that it can react on an overload situation in a 
controlled way. However it is possible that a situation happens where the security 
measures are no longer sufficient.                                                                                                                                                          
In such case it shall be ensured that the system cannot reach an undefined and thus 
potentially insecure state. In an extreme case this means that a controll ed system 
shutdown is preferable to uncontrolled failure of the security functions and thus loss of 
system protection.                                                                                                                                                                  
The vendor shall provide a technical description of the network products' Over Load 
Control mechanisms (especially whether these mechanisms rely on cooperation of 
other network elements) and the accompanying test case for this requi rement will check 
that the description provides sufficient detail in order for an evaluator to understand how 
the mechanism is desig ned.                 
 [Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0  . section 4.2.3.3.3]  
8.3 Filtering IP Options  
Requirement:  
 
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.  
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.2.4.1.1.3]  
 
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 27 of 45 
© NCCS 2020  
 
 
Section 9: Vulnerability Testing Requirements  
9.1 Fuzzing – Network and Application Level  
Requirement:  
 
It shall be ensured that externally reachable services are reasonably robust when 
receiving unexpected input  
 
Note : Vendor is expected to provide the list o f protocols supported by the Network 
product .  
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.4.4]  
 
 
9.2 Port Scanning  
Requirement:  
 
It shall be ensured that on all network interfaces, only documented ports on the 
transport layer respond to requests from outside the system.  
 
The test for this requirement can be carried out using a suitable tool or manually 
performed as 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.  
  
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .section 4.4.2]  
 
9.3 Vulnerability Scanning  
Requirement:  
 
The purpose of vulnerability scanning is to ensure that there no known vulnerabilities (or 
that relevant vulnerabilities are identified and remediation plans in place to mitigate 
them) on the Network Product, both in the OS and in the applications installed, that can 
be detected by means of automatic testing tools via the Internet Protocol enabled 
network interfaces.  
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 28 of 45 
© NCCS 2020  
 
Vulnerability scanning tools may also report false positives and they sha ll be 
investigated and documented in the test report.  
 
The test for this requirement can be carried out using a suitable tool or manually 
performed as described below. If a tool is used then the tester needs to provide 
evidence, e.g. by referring to the do cumentation of the tool, that the tool actually 
provides functionality equivalent to the steps described below.  
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0  section 4.4.3]  
 
Section 10:  Operating System  
10.1 Growing Content Handling  
Requirements:  
 
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.  
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0  . Section 4.2.4.1.1.1]  
 
10.2 Handling of ICMP  
Requirement:  
 
Processing of ICMPv4 and ICMPv6 packets which are not required for opera tion 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.  
 
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 mar ked as 
"Optional" in below table.     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 29 of 45 
© NCCS 2020  
 
 
 
 
Type (IPv4)  Type (IPv6)  Description  Send  Respond to  
0  128 Echo Reply  Optional  
(i.e. as automatic 
reply to "Echo 
Request")  N/A 
3 1 Destination Unreachable  Permitted  N/A 
8 129 Echo Request  Permitted  Optional  
11 3 Time Exceeded  Optional  N/A 
12 4 Parameter Problem  Permitted  N/A 
N/A 2 Packet Too Big  Permitted  N/A 
N/A 135 Neighbour Solicitation  Permitted  Permitted  
N/A 136 Neighbour Advertisement  Permitted  N/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)  
5 137 Redirect  N/A N/A Not Permitted  
13 N/A Timestamp  N/A Not Permitted  N/A 
14 N/A Timestamp 
Reply  Not Permitted  
(i.e. as 
automatic 
reply to 
"Timestamp")  N/A N/A 
N/A 133 Router 
Solicitation  N/A Not Permitted  Not Permitted  
N/A 134 Router N/A N/A Not Permitted     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 30 of 45 
© NCCS 2020  
 
Advertisement  
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .  Section 4.2.4.1.1.2]  
 
 
10.3. Authenticated Privilege Escalation only  
Requirement:  
 
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 acc ount 
without re -authentication. Implementation example: Disable insecure privilege escalation 
methods so that users are required to (re -)login directly into the acco unt with the 
required permissions.  
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0   . Section 4.2.4.1.2.1 ] 
 
10.4 System account identification  
Requirement:  
 
Each system accoun t in Operating system of the N etwork product  shall have a unique 
identification, the Vendor  to provide information on implementation mechanism for this 
requirement .  
 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0  . Section 4.2.4.2.2 ] 
 
10.5 OS Hardening - Kernel Security  
 
Requirement:  
 
Vendor may submit the process for OS Hardening undertaken to justify that the OS is 
sufficiently hardened and Kernel based applications / functions not nee ded for the 
operation of the Network product  are deactivated  
 
Vendor  to provide information  on steps taken in this regard.  
 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . Section 4.3.3.1.2 ]    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 31 of 45 
© NCCS 2020  
 
10.6 No automatic launch of removable media  
Requirement:  
 
The Network product  shall not automatically launch any application when removable 
media device such as CD -, DVD -, USB -Sticks or USB -Storage drive is connected. If the 
operating system supports an automatic launch, it shall be deactivated unless it is 
required to support avai lability requirements.  
 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0  . Section 4.3.3.1.3 ] 
 
 
10.7. External file system mount restrictions  
 
 
Requirement:  
 
If normal users are allowed to mount external file systems (attached locally or via the  
network), OS -level restrictions shall be set properly in order to prevent privilege 
escalation or extended access permissions due to the contents of the mounted file 
systems  
. 
 [Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0. Section 4.3.3.1.6]  
 
Section 11: Web Servers  
The following security re quirements are applicable for Network products  supp orting 
web server functionality  
11.1 HTTPS  
Requirement:  
 
The communication between Web client and Web server shall be protected using  
industry standard secured communication protocols such as TLS/HTTPS.  
 
Cipher suites with NULL encryption shall not be supported.  
 
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0  . section 4.2.5.1]     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 32 of 45 
© NCCS 2020  
 
11.2 Webserver logging  
Requirement:  
 
Access to the webserver (  both successful as well as failed attempts) shall be logged. 
The web server log shall contain the following information:  
 
- Access timestamp  
- Source (IP address)  
- Account (if known)  
- 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  
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .section 4.2.5.2.1]  
11.3 HTTP User sessions  
Requirement:  
 
To protect user sessions the Network Product shall support the following session ID and 
session cookie requirements:  
 
(i). The session ID shall uniquely identify the user and distinguish the session from 
all other active sessions.  
(ii). The session ID shall be unpredictable.  
(iii). The session ID shall not contain sensitive information in clear text (e.g. account 
number, social security, etc.).  
(iv). In addition to the Session Idle Timeout (see clause 5.2.3.5.2  Protecting sessions 
– Inactivity timeout), the Network Product shall terminate automatically sessions after a 
configurable maximum lifetime This maximum lifetime defines t he 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 maxi mum lifetime shall be set 
to 8 hours.     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 33 of 45 
© NCCS 2020  
 
(v). Session ID's shall be regenerated for each new session (e.g. each time a user 
logs in).  
(vi). The session ID shall not be reused or renewed in subsequent sessions.  
(vii). The Network Product shall not use persiste nt 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.  
(viii).  Where session cookies are used the attribute 'HttpOnly' shall be set to true.  
(ix). Where session cookies are used the 'domain' attribute shall be set to ensure that 
the cookie can only be sent to the specified domain.  
(x). Where session cookies are used the 'path' attribute shall be set to ensure that the 
cookie can only be sent to the specified direc tory or sub -directory.  
(xi). The Network Product shall not accept session identifiers from GET/POST 
variables.  
(xii). The Network Product shall be configured to only accept server generate session 
ID's. 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .  section 4.2.5.3]  
11.4 HTTP input validation  
Requirement:  
 
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.  
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.2.5.4]  
 
11.5 No system  privileges  
Requirement:  
 
No web server  processes  shall run with system  privileges. This is best achieved if the 
web server runs under an account that has minimum privileges. If a process  is started  
by a user  with system  privileges,  execution  shall be transferred  to a different  user 
without  system privileges  after the start.     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 34 of 45 
© NCCS 2020  
 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.3.4.2]  
 
11.6 No unused HTTP methods  
Requirement:  
 
HTTP  methods  that are not required  shall be deactivated. Standar d request s to web 
server s only use GET, HEAD, and POST . If other method s are required , they shall not 
introduce se curity leaks such as TRACK or TRACE.  
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0   section 4.3.4.3]  
 
 
11.7 No unused add -ons 
Requirement:  
 
All optional  add-ons and components  of the web server  shall be deactivated  if they are 
not required.  In particular, CGI or other scripting components, Server Side Includes 
(SSI), and WebDAV shall  be deactivated  if they are not required.  
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0  . section 4.3.4.4]  
 
 
11.8  No compiler, interpreter, or shell via CGI or other server -
side   scripting  
Requirement:  
 
If CGI (Common Gateway Interface) or other scripting technology is used,  the CGI 
directory - or other corresponding scripting directory  - shall not include  compilers  or 
interpreters  (e.g. PERL  interpreter, PHP interpreter/compiler,  Tcl interpreter/compiler  or 
operating  system  shells).  
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .section 4.3.4.5]  
 
11.9 No CGI or other scripting for uploads  
Requirement:  
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 35 of 45 
© NCCS 2020  
 
If CGI or other scripting technology is used,  the associated CGI/script  directory  shall not 
be used  for uploads.  
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .  section 4.3.4.6]  
 
11.10 No execution of system commands with SSI  
Requirement:  
 
If Server  Side Includes  (SSI)  is active,  the execution  of system  commands  shall be 
deactivated.  
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.3.4.7]  
 
11.11 Access rights for web server configuration  
Requirement:  
 
Access  rights  for web server  configuration  files shall only be granted  to the owner  of the 
web server  process  or to a user with system  privileges. Implementatio n example : Delet e 
"read " and "write " acces s rights for "others. " Only grant "write " acces s to the user who 
configures  the web server.  
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0   section 4.3.4.8]  
 
11.12 No default content  
Requirement:  
 
Defaul t conten t (examples , help files, documentation , aliases ) that is provide d with the 
standar d installatio n of the web server  shall be removed.  
[Referen ce: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.3.4.9]  
 
11.13 No directory listings  
Requirement:  
 
Directory  listings  (indexing)  / "Directory browsing" shall be deactivated.  
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 .  section 4.3.4.10]     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 36 of 45 
© NCCS 2020  
 
11.14 Web server information in HTTP headers  
Requirement:  
 
The HTTP  header  shall not include  information  on the version  of the web server  and the 
modules/add -ons used.  
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.3.4.11]  
 
 
11.15 Web server information in error pages  
Requirement:  
 
User -define d error page s shall not includ e versio n informatio n abou t the web serve r 
and the modules/add -ons used . Error  messages  shall not include  internal  information  
such as  internal  server  names,  error  codes,  etc. Default error pages of the web server 
shall be replaced by error pages defined by the vendor.  
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.3.4.12]  
 
 
11.16 Minimized file type mappings  
Requirement:  
 
File type- or script -mappings  that are not required  shall be deleted,  e.g. php, phtml,  js, 
sh, csh, bin,  exe, pl, vbe, vbs. 
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.3.4.13]  
 
 
11.17 Restricted file access  
Requirement:  
 
Restrictive  access  rights  shall be assigned  to all files  which  are directly  or indirectly  (e.g. 
via links  or in virtual  directories)  in the  web server's  document  directory.  In particular,  the 
web server  shall not be able to access  files which  are not meant  to be delivered.  
[Reference:  TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0   section 4.3.4.14]  
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 37 of 45 
© NCCS 2020  
 
11.18 Execute rights exclusive for CGI/Scripting directory  
Requirement:  
 
If CGI or other scripting technology is used, only the CGI/Scripting directory is 
configured with execute rights. Other directories used or meant for web content do not 
have execute rights.  
[Reference: TSDSI STD T1.3GPP 33.117 -14.2.0 V.1.0.0 . section 4.3.4.15]  
 
Section 12: Other Security requirements  
12.1.  Remote Diagnostic Procedure – Verification  
Requirement:  
If the Network product  is providing Remote access for troubleshooting purposes/alarm 
maintenance,  then it should be allowed only fo r authorized users and all activities 
performed by the remote user is to be logged with parameters like User id , time stamp,  
interface type,  event level (e.g. CRITICAL, MAJOR, MINOR), result type (e.g. 
SUCCESS, FAILURE).  
 
12.2.  No Password Recovery  
Requirement:  
Network devices have a function that resets the current system password .In the event 
of system password reset ,  the entire configuration  of the Network product shall be 
irretrievably deleted .  
 
No provision should exitsts for password recovery  
 
12.3.  Secure System Software Revocation  
Requirement:  
Once the software image is legally updated, it should not be possib le to roll back to a 
previous exploitable software image.  In case roll back is essential, it shall be do ne only    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 38 of 45 
© NCCS 2020  
 
by the administrator. Network product shall support a well -established control 
mechanism for rolling back to previous exploitable software imag e.  
12.4.  Software Integrity Check – Installation  
Requirement:  
Network product should validate the software package integrity before the installation 
stage. Tampered software shall not be executed or installed if integrity check fails.  
 
12.5.  Software Integrity Check – Boot 
Requirement:   
The Network product  shall verify the integrity of a software component typically by 
comparing the result of a measurement (typically a cryptographic hash /CRC ) of the 
component to the expected reference value . 
The Network product  shall support the possibility to verify software image integrity at 
boot time, detecting, for example, software image tampering and/or unauthorized 
software image updates.  
 
12.6.  Unused Physical Interfaces Disabling  
Requirement:    
The network product shall support the mechanism to verify all the physically accessible 
interfaces. Physically accessible Interfaces which are not  under use shall be disabled by 
configuration that they remain inactive even in the event of a reboot.  
Note : List of the default  used Physical Interfaces/Ports as given by the vendor shall 
match the list of Physical Interfaces/Ports that are necess ary for the operation of the 
Network product.  
12.7.  No De fault Profile  
Requirement:      
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 39 of 45 
© NCCS 2020  
 
Predefined or default user accounts shall be deleted or disabled. Default accounts such 
as guest, master are generally pre-configured with known or nil authenticatio n attribute 
and therefore such standard user s shall be deleted  or disabled  
12.8.  Security Algorithm Modification  
Requirement:   
When Networ k product is establishing  session / communication channel  with other 
Network product or while communication in the progress , Network product shall have 
protection against  a downgrade attack /bidding down attack for  the use of a weaker 
algorithm.  
12.9.  Control Plane Traffic Protection  
Requirement:  
 
Control pla ne traffic shall be protected in the Network product  using standard 
cryptographic mechanisms i.e by using the i ndustry standard cryptographic secure 
protocols such as TLS, IPSec, etc.  Control plane traf fic shall be protected in the 
Network product  using standard cryptographic mechanisms i.e by using the industry 
standard cryptographic secure protocols such as TLS, IPSec, etc  
ABBREVIATIONS  
 
AAA Server    Authentication, Authorization, and Accounting  Server  
ACL    Access Control Lists  
AES    Advanced Encryption Standard  
CERT     Computer emergency response teams  
CVE    Common Vulnerabilities and Exposures  
CWE     Common Weakness Enumeration  
DDOS     Distributed Denial of Service  
NE    Network Element  
EMS     Element management System  
FIPS     Federal Inform ation Processing Standards  
HTTP     Hypertext Transfer Protocol  
HTTPS    Hypertext Transfer Protocol Secure  
IPSec VPN    Internet Protocol Security Virtual Private Network  
MC/DC    Modified Condition / Decision  Coverage  
MD5     Message Digest Algorithm  
MISRA    Motor Industry Software Reliability Association     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 40 of 45 
© NCCS 2020  
 
NIST     National Institute of Standards and Technology  
NMS     Network management System  
NTP    Network Time Protocol  
OMC     Operation and maintenance Console  
OS    Operating System  
OSPF     Open Shortest Path First  
PTP    Precision Time protocol  
RADIUS    Remote Authentication Dial -In User Service  
RIP    Routing Information Protocol  
SFTP     Secure File Transfer Protocol  
SHA    Secure hash Algorithm  
SIP    Session Initiation Protocol  
SNMP     Simple Network Management Protocol  
SSH    Secure Shell  
SSL    Secure Sockets Layer  
TFTP     Trivial File Transfer Protocol   
TLS VPN    Transport Layer Security  Virtual Private Network  
URPF     Unicast Reverse Path Forwarding  
ST    Security Target  
TOE    Target Of Evaluation  
TSF    TOE Security Functionality  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 41 of 45 
© NCCS 2020  
 
IP Router Specific  Security Requirements  (RSR) 
Table Of Contents  
 
1.0 AUDIT EVENT GENERATION  ................................ ................................ ................................ ................  42 
2.0 AUDIT DATA PROTECTION  ................................ ................................ ................................ ..................  42 
3.0 CONTROL  PLAN E TRAFFIC PROTECTION  ................................ ................................ ......................  43 
4.0 TRAFFIC FILTE RING – NETWORK LEVEL  ................................ ................................ .........................  43 
5.0 TRAFFIC FILTERING – APPLI CATIONS AND SERVICES  ................................ ................................  43 
6.0  DATA PLANE TRAFFIC PROTECTION  ................................ ................................ ................................  44 
7.0 NAT ( NETWORK ADDRESS TRANSLATION) SERVICES SUPPORT  ................................ .............  44 
8.0 IP SEC VPN SUPPORT  ................................ ................................ ................................ ............................  44 
9.0 ACCESS BANNERS  ................................ ................................ ................................ ................................ . 45 
10.0 INTER –VLAN ROUTING SUPPORT ( LANGUAGE)  ................................ ................................ .........  45 
11.0. ROUTER UPDATES SECURITY ------------------------------------------------------- -------- 6 
ABBREVIATIONS  ................................ ................................ ................................ ...............................  45 
 
     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 42 of 45 
© NCCS 2020  
 
  
 
1.0 Audit event generation  
Requirements : 
 
In addition to the  list of auditable events covered in  CSR 5.2. the following additional 
auditable events should also be met by  Router . 
 
Event Types  Description  Event data to be logged  
a) Access Control 
Policy violations  Any failure of a packet to 
match an ACL rule allowing 
traversal of the router  Date /Time stamps, The 
source, destination and 
protocol attributes of the 
traffic  
b) attempt to initiate 
manual software 
update, initiation of 
software update, 
completion of update  Logs generation  user identity, Timestamp,  
Outcome of event (Success 
or failure), Activity 
performed  
 
 
c) All use of 
identification and 
authentication 
mechanism  
  
 
All use of identification and 
authentication mechanism  
 user identity, origin of 
attempt (e.g.IP address), 
Timestamp, outcome of 
event (Success or failure  
 
2.0 Audit data protection  
Requirements : 
 The security event log shall be access controlled (file access rights), so only privilege 
users have  access to read  the log files but not allowed to delete the log files . This 
requirement  is applicable also applicable to  Administrator   
 
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 43 of 45 
© NCCS 2020  
 
 
3.0 Control  Plane Traffic Protection  
Requirements : 
Router  functionalities like building Routing tables , Forwarding tables , MAC Tables , 
crypto algorithm/Key negotiations are considered under control plane traffic .  
Dynamic routing protocols( RIP, OSPF and BGP) are the most widely deployed which  
comes under co ntrol plane, a malicious user may spoof or modify valid routing protocol 
messages and corrupt or chan ge routing tables of a network. This might result in 
redirection of some or all network traffic, connectivity problems, excessive bandwidth 
consumption and potential denial of service of both the router and the routing protocol. 
Failure to secure the exchange of routing information allows an attacker to introduce 
false routing information into the network . 
Control plane traffic shall be protected  by using Rou ting protocol authentication 
mechanism, Passive interface (stop sending updates on interfaces that face end users 
i.e. on LA N), Route filtering  
 
4.0 Traffic Filtering – Network Level  
Requirement s: 
Router  shall support filter mechanism based on the following  
a) To filter on the basis of the Source IP/Destination IP , any portion of the protocol 
( TCP/UDP) header (Source Port/Destination Port numbers , Header Flags etc..) . 
b) Filter based on type of  access ( Lik e Telnet/SSH /HTTP etc..) .  
5.0 Traffic Filtering – Applications and Services  
Requirements : 
 
 Router  shall permit /restrict the reach ability  of applications services so that they can 
only be reached on interfaces  where their usage is required.  
 
Router  shall support  traffic  filtering for following prot ocols, applications / services . 
 
PING ,BGP, HTTP , OSP F, RIP, SSH, TELNET     
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 44 of 45 
© NCCS 2020  
 
 
6.0  Data Plane T raffic Protection  
Requirements : 
 
Data plane traffic is customer generated application traffic by hosts .  
 
Security Threats like IP spoofing ( Blind spoofing /No blind IP spoofing) , IP Packet 
header with o ptions like IP Source Routing, Low TTL value attacks should be 
considered.  
 
To secure Data plane traffic  Router should at least  support protection mechanisms like 
Unicast Reverse path forwarding( URPF), prevent IP spoofing with ACL’s,  preventing 
ICMP traffic with ACL’s , ACL’s to filter Packets wit h IP options, Disable with IP sou rce 
routing options  
 
 
7.0 NAT ( Network Address Translation) services 
support  
    Requirements : 
 
       Router supports  NAT/PAT  services and should have protection mechanism 
against NAT Traversal attacks , Pin hole attacks  
8.0 IP Sec VPN support  
Requirements : 
 
If Router supports   IPSec VPN then feature should exists  Site to Site  configurations.  
    
Document Name  ITSAR for Mobility Management Entity (MME)  
Doc. No.  Version  Release  date  Enforcement date  
ITSAR -IPR-0001 1.0 XX-XXX-XXXX  XX-XXX-XXXX  
Page 45 of 45 
© NCCS 2020  
 
9.0 Access Banners  
Requirements : 
Router shall  provides the requirement of  banner is displayed prior to the establishment 
dialogue for a session.  
 
Before e stablishing a user session, Router  shall display an advisory warning  message 
regarding unauthorized use of Router  
 
10.0 Inter –VLAN Routing support  
Requirements : 
 
 Inter –VLAN routing functionality by default is not permitted , only permitted 
configuration by administrator  . 
 
11.Router updates security   
 
For Inter AS routing updates , facility should exists for administrative accept /reject 
routing updates to prevent Routing table poisioining attack s  
 
ABBREVIATIONS  
NE     Network Element  
EMS     Element management System  
HTTP     Hypertext Transfer Protocol  
HTTPS    Hypertext Transfer Protocol Secure  
IPSec VPN    Internet Protocol Security Virtual Private Network  
OSPF     Open Shortest Path First  
BGP     Border Gateway Protocol  
RIP     Routing Information Protocol  
SFTP     Secure File Transfer Protocol  
SHA    Secure hash Algorithm  
SSH    Secure Shell  
SSL    Secure Sockets Layer  
TFTP     Trivial File Transfer Protocol   
VLAN     Virtual Local Area Network  
ICMP     Internet Control Message Protocol