1. Network Slice Selection Function (NSSF) Cloud Native User's Guide
  2. Overview

1 Overview

This document provides information on how to use the Oracle Communications Network Slice Selection Function (OCNSSF) in the cloud native 5G core network.

Network slices enables the users to select customized networks with different functionality (Example: mobility), performance requirements (Example: latency, availability, reliability etc). Network slices may differ for supported features and network function optimisations. In such cases, network slices may have different S-NSSAIs with different slice and service types. The user can deploy instances of multiple network slices delivering exactly the same features but for different groups of User Equipments (UE). As these instances deliver a different committed service because they are dedicated to a customer, in which case such network slices may have different S-NSSAIs with the same slice or service type but different slice differentiators. OCNSSF fulfills the requirement for determining the individual network function pertaining to a slice. This section includes information about the role of OCNSSF in the 5G Service based architecture.

Network Slice Selection Function is a functional element that supports the following functionalities:
  • OCNSSF enables the Access and Mobility Management Function (AMF) to perform initial registration and PDU session establishment.
  • OCNSSF uses an NF Service Consumer (AMF) to update the S-NSSAI(s) the AMF supports and notify any change in status.
  • OCNSSF selects the network slicing instance (NSI) and determines the authorized Network Slice Selection Assistance Information (NSSAIs) and AMF to serve the UE.
  • AMF can retrieve NRF, NSI ID, target AMFs as part of UE initial registration and PDU establishment procedure.
  • OCNSSF interaction with NRF allows retrieving specific NF services to be used for registration request.

NSSF is responsible for providing the following information as and when queried by the AMF:

  • Allowed NSSAIs
  • Configured NSSAIs
  • Restricted NSSAIs
  • Candidate AMF List (in case of registration)
  • Network Slice instance ID (for PDU registration)
  • Slice-level NRF information (for PDU Connectivity)

OCNSSF supports the above functions through the following NSSF services:

  • Network Slice Selection service (Nnssf_NSSelection): This service is used by an NF Service Consumer (AMF) to retrieve the information related to network slice. Network Slice Selection Service enables Network Slice selection in the serving Home Public Land Mobile Network (HPLMN).
  • NS-Availability Service (Nnssf_NSAvailability): This service is used by an NF Service Consumer (AMF) to update the S-NSSAI(s) the AMF supports on a per TA basis on the NSSF. Also to notify any change in status, on a per TA basis, of the SNSSAIs available per TA (unrestricted) and the restricted SNSSAI(s) per PLMN in that TA in the serving PLMN of the UE.

NSSF Architecture

NSSF comprises of various microservices deployed in Kubernetes based Cloud Native Environment (CNE, example: OCCNE). Some common services like logs or metrics data collection, analysis and graphs or charts visualization, etc. is provided by the environment. The microservices integrates with them and provide them necessary data. The following diagram describes the overall architecture of the NSSF:

Figure 1-1 Network Slice Selection Function Architecture Diagram

img/archtitecture_1.3.png

The architecture has the following components:

NS Selection Microservice

This microservice receives all NS-Selection requests and provides network slice information.

NS Availability Microservice

This service supports the NS-Availability service of NSSF and stores subscriptions and AMF data.

NS Subscription Microservice

This microservice sends notifications based on subscribed events through NS Availability. Notifications are sent to subscribed AMFs to signify changes in authorization state with respect to S-NSSAIs on TAI as per 3GPP TS 29.531.

NS Configuration Microservice

This microservice is responsible for configuring policy rules. This microservice implements a REST messaging server that receives configuration HTTP messages, validates and stores the configuration in the database.

NRF Client Microservice

This microservice registers with the NRF and sends periodic heartbeats, also maintains subscriptions with NRF for AMF sets.
  • NRF Registration and Heartbeat: First the Registration profile is configured using helm. Then the Performance service calculates load and capacity of NF. NS Registration requests load and capacity from performance service and send it to NRF with heartbeat.
  • NRF Subscription: NSSF subscribes to NRF for AMF based on Target AMF Set and Region ID for Registration and Deregistration and load update.

OCNSSF Ingress Gateway Microservice

This microservice is an entry point for accessing OCNSSF supported service operations and provides the functionality of OAuth validator.

OCNSSF Egress Gateway Microservice

This microservice is responsible to route OCNSSF initiated egress messages to other NFs.

NSSF Supported Features

This section explains the NSSF supported features.

1. OAuth

  • OCNSSF supports OAuth 2.0 Access Token based authorization for NF to NF authorization.
  • OCNSSF performs the task of OAuth validator for call scenarios to NS-Selection service and NS-Availability service.
  • OCNSSF acts like an OAuth client for Notification messages towards AMF.
Steps to Enable OAuth in NSSF

Prerequisites to enable OAuth
  • There must be an OAuth token generator for OCNSSF default token provided is NSSF.
  • Generate Kubernetes secret using NRF Public key as per section in OCNSSF installation guide.
  • NSSF must have Public Key of NRF.
    • Public Key should be in the format "{nrfInstanceId}_{Signing Algorithm}.pem" where nrfInstanceId is Instance Id of NRF and Signing Algorithm can have following values: 
    ES256: ECDSA using P-256 and SHA-256
ES384: ECDSA using P-384 and SHA-384
ES512: ECDSA using P-521 and SHA-512
RS256: RSASSA-PKCS-v1_5 using SHA-256
RS384: RSASSA-PKCS-v1_5 using SHA-384
RS512: RSASSA-PKCS-v1_5 using SHA-512
PS256: RSASSA-PSS using SHA-256 and MGF1 with SHA-256
PS384: RSASSA-PSS using SHA-384 and MGF1 with SHA-384
PS512: RSASSA-PSS using SHA-512 and MGF1 with SHA-512
    • Store all .pemfiles in a secret in ocnssf namespace.
  • NSSF must register with all services over which OAuth validation might be supported.
OCNSSF as OAuth Validator

OCNSSF performs the following tasks after receiving a request when OAuth is enabled:

  1. NSSF ensures the integrity of the token by verifying the signature using NRF’s public key.
  2. If integrity check is successful, NSSF verifies the claims in the token as follows:
    1. NF-ID match: NSSF ensures that the nf-id in claim is its self nf-id.
    2. NF-Type match: NSSF validates that the target nf-type is NSSF.
    3. Token expiry Validation: Checks the difference between current time and validity time is less than helm parameter ingress_gateway.allowedClockSkewSeconds.

    Sample configuration at OCNSSF to enable OAuth validator functionality:

    ingress-gateway:
  # NFType of service producer.Mandatory Parameter
  nfType: NSSF
  # NF InsatanceId of service producer.Mandatory Parameter
  nfInstanceId: fe7d992b-0541-4c7d-ab84-c6d70b1bae31
  # Comma-seperated list of services hosted by service producer.Mandatory Parameter
  producerScope: ns-selection,ns-availability
  # set this value if clock on the parsing NF(producer) is not perfectly in sync with the clock on the NF(consumer) that created the JWT.
  # Default value is 0.
  allowedClockSkewSeconds: 1000
  # Name of the secret which stores the public key(s) of NRF. Creation Of Secret is described in Oauth Validator module below.
  nrfPublicKeyKubeSecret: ocnssf-auth-secret
  # Namespace of the NRF publicKey Secret.
  nrfPublicKeyKubeNamespace: ocnssf
  # Values can be "strict" or "relaxed".
  # "strict" means that incoming request without "Authorization"(Access Token) header will be rejected.
  # "relaxed" means that if incoming request contains "Authorization" header, it will be validated.If incoming request does not contain
  # "Authorization" header, validation will be ignored. Default value is "strict"
  validationType: strict
OCNSSF as OAuth client

OCNSSF performs following tasks before sending a notification when OAuth is enabled:

  1. OCNSSF sends nnrf-accesstoken GET with nf-type as AMF and nf-id as AMF-ID which is stored at NSSF during subscription and request to OCNRF.
  2. OCNSSF stores the token in cache and reuses the same token till token expires.
  3. OCNSSF adds authentication header using the token provided by NRF to send notification message to AMF.

Sample configuration at OCNSSF to enable OAuth client functionality:

 egress-gateway:
   # OAuth token provider in OCNSSF case this is NRF ,NRF's ${HOSTNAME}:{PORT}.
   nrfAuthority: 10.75.181.00:8080
   # NFType of service consumer.Mandatory Parameter
   nfType: AMF
   # NF InstanceId of Service Consumer.Mandatory Parameter
   nfInstanceId: fe7d992b-0541-4c7d-ab84-c6d70b1b01b1
   # Flag to enable or disable oauth client. If not defined, Default value 'false' will be injected.
   oauthClientEnabled: true

2. HTTPS

HTTPS enables end to end encryption of messages to ensure security of data. HTTPS requires creation of TLS (Mutual TLS by 2 way exchange of ciphered keys)

Steps to Enable HTTPS in OCNSSF

Certificate Creation

To create certificate user must have the following files:

  • ECDSA private key and CA signed certificate of OCNRF (if initial algorithm is ES256)
  • RSA private key and CA signed certificate of OCNRF (if initial algorithm is RSA256)
  • TrustStore password file
  • KeyStore password file
  • CA certificate

Secret Creation

Execute the following command to create secret:
$ kubectl create secret generic ocnssfaccesstoken-secret --from-file=ecdsa_private_key_pkcs8.pem --from-file=rsa_private_key_pkcs1.pem
      --from-file=trustStorePassword.txt --from-file=keyStorePassword.txt --from-file=ecdsa_ocnssf_certificate.crt--from-file=rsa_ocnssf_certificate.crt -n
    ocnssf

Certificate and Key Exchange

Once the connection is established, both parties can use the agreed algorithm and keys to securely send messages to each other. We will break the handshake up into 3 main phases:

  • Hello
  • Certificate Exchange
  • Key Exchange
  1. Hello: The handshake begins with the client sending a ClientHello message. This contains all the information the server needs in order to connect to the client via SSL, including the various cipher suites and maximum SSL version that it supports. The server responds with a ServerHello, which contains similar information required by the client, including a decision based on the client’s preferences about which cipher suite and version of SSL will be used.
  2. Certificate Exchange: Now that contact has been established, the server has to prove its identity to the client. This is achieved using its SSL certificate, which is a very tiny bit like its passport. An SSL certificate contains various pieces of data, including the name of the owner, the property (Example: domain) it is attached to, the certificate’s public key, the digital signature and information about the certificate’s validity dates. The client checks that it either implicitly trusts the certificate, or that it is verified and trusted by one of several Certificate Authorities (CAs) that it also implicitly trusts. The server is also allowed to require a certificate to prove the client’s identity, but this only happens in very sensitive applications.
  3. Key Exchange: The encryption of the actual message data exchanged by the client and server will be done using a symmetric algorithm, the exact nature of which was already agreed during the Hello phase. A symmetric algorithm uses a single key for both encryption and decryption, in contrast to asymmetric algorithms that require a public/private key pair. Both parties need to agree on this single, symmetric key, a process that is accomplished securely using asymmetric encryption and the server’s public/private keys.

The client generates a random key to be used for the main, symmetric algorithm. It encrypts it using an algorithm also agreed upon during the Hello phase, and the server’s public key (found on its SSL certificate). It sends this encrypted key to the server, where it is decrypted using the server’s private key, and the interesting parts of the handshake are complete. The parties are identified that they are talking to the right person, and have secretly agreed on a key to symmetrically encrypt the data that they are about to send each other. HTTP requests and responses can be sent by forming a plain text message and then encrypting and sending it. The other party is the only one who knows how to decrypt this message, and so Man In The Middle Attackers are unable to read or modify any requests that they may intercept.

OCNSSF supports following cipher suites

- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

HTTPS Encrypted Communication

Once the HTTPS handshake is complete all communications between the client and the server are encrypted. This includes the full URL, data (plain text or binary), cookies and other headers.

The only part of the communication not encrypted is what domain or host the client requested a connection. This is because when the connection is initiated an HTTP request is made to the target server to create the secure connection. Once HTTPS is established the full URL is used.

This initialization only needs to occur once for each unique connection. This is why HTTP/2 has a distinct advantage over HTTP/1.1 since it multi-plexes connections instead of opening multiple connections.

Helm Configuration to enable HTTPS on NSSF:
Sample values.yaml to enable HTTPS on NSSF:
 #Enabling it generates key and trust store for https support
    initssl: true       (Note: secret has to be created if its set to true)
#If true opens https port on egress gateway
   enableincominghttps: false
#Enabling it egress makes https request outside
   enableoutgoinghttps: true
 (Note: initssl should be set to true if either enableincominghttps or enableoutgoinghttps is enabled )
#KeyStore and TrustStore related private key and Certificate configuration   (Note: The configuration names specified should be same as the     file names specified when creating secret)
      
   privateKey: 
   k8SecretName: accesstoken-secret
   k8NameSpace: ocnssf
   rsa:
   fileName: rsa_private_key_pkcs1.pem
     
   certificate:
   k8SecretName: accesstoken-secret
   k8NameSpace: ocnssf
   rsa:
   fileName: ocnssf.cer
   
   caBundle:
   k8SecretName: accesstoken-secret
   k8NameSpace: ocnssf
   fileName: caroot.cer
     
   keyStorePassword:
   k8SecretName: accesstoken-secret
   k8NameSpace: ocnssf
   fileName: key.txt
   
   trustStorePassword:
   k8SecretName: accesstoken-secret
   k8NameSpace: ocnssf
   fileName: trust.txt
    
   initialAlgorithm: RSA256

3. Rate Limiting

Rate limiting for Ingress and Egress Messages

OCNSSF uses Bucket4j which uses Token Bucket Algorithm to enable rate limiting. With the token-bucket algorithm, user has 3 configuration points.

The token bucket algorithm has following concepts:

bucketCapacity: The maximum number of token the bucket can hold.

duration: The amount of time between the refills.

refillRate:The number of tokens that are added to the bucket during a refill.

(where duration: in seconds (M) ,burstCapacity: (C) ,refillRate: (N))

  • N tokens are added to the bucket every M seconds.
  • The bucket can hold at the most C tokens. If a token arrives when the bucket is full, it is discarded.

Ingress Rate Limiting

To avoid unexpected behavior and DOS attacks ,OCNSSF allows user to enable rate limiting in ingress messages. OCNSSF allows user to configure a cap on max number of incoming messages at a given duration. User has an option to configure a max cap on number of ingress request per service.

Steps to Enable Ingress Rate Limiting

OCNSSF allows at the max of {burstCapacity}/ {refillRate} number of messages in a duration signified by parameter {duration}.

To enable ingress rate limiting at OCNSSF ingress_gateway.rateLimiting.enabled must be set to true.

Global Ingress Rate Limiting

When globalIngressRateLimiting.enabled is set to true then rate limiting is applied for all ingress messages.

Route Based Rate Limiting

OCNSSF provides option to configure route based rate limiting and method based rate limiting which enables NSSF to throttle messages per Service per method.

In the below example OCNSSF allows 80 GET requests on NS-Selection service for every 2 seconds.

Sample ingress rate limiting configuration: 

#Rate limiting configuration
rateLimiting:
  enabled: true
routeRateLimiting:
  enabled: true
# Global rate limiting configuration
globalIngressRateLimiting:
  enabled: true
  duration: 2 # in seconds
  burstCapacity: 100
  refillRate: 1
 
routesConfig:
- id: nsselection_mapping
  uri: http://ocnssf-nsselection:5745
  path: /nnssf-nsselection/**
  order: 1
#Route level limiting configuration enabled for NS-Selection
  methodRateLimiting: # specify the list of methods u have to rate limit
  - method: GET
    burstCapacity: 80
    refillRate: 1
    duration: 2
#Route level limiting configuration not enabled for NS-Availability
- id: availability_mapping
  uri: http://ocnssf-nsavailability:5745
  path: /nnssf-nssaiavailability/**
  order: 2
- id: nsconfig_mapping
  uri: http://ocnssf-nsconfig:5755
  path: /nnssf-configuration/**
  order: 3

Egress Rate Limiting

OCNSSF sends notification messages to AMF based on configuration change of Supported SNSSAI/s in a TAI. Notification messages can be throttled by operator by enabling egress message rate limiting.

Steps to Enable Egress Rate Limiting

To enable rate limiting egress-gateway.notificationRateLimit.enabled must be set to true.

As per the below example, OCNSSF has a max cap on 200 notifications per second:

egress-gateway:
  notificationRateLimit:
    enabled: false
    duration: 1
    bucketCapacity: 200
    refillRate: 1

4. HTTP Options

HTTP headers let the client and the server pass additional information with an HTTP request or response.

The Content-Encoding, when present in response, its value indicates which encoding were applied to the entity-body. It lets the client know how to decode in order to obtain the media-type referenced by the Content-Type header.

The Accept-Encoding header is used to find out the encoding supported by the server. The server responds with the type of encoding used, indicated by the Accept-Encoding response header.

Syntax:

Accept-Encoding: gzip

Content-Encoding: gzip

5. 3gpp-Sbi-Target-Apiroot Header Support

3gpp-Sbi-Target-Apiroot header is used by an HTTP client to indicate the apiRoot of the target URI when communicating indirectly with the HTTP server via an SCP using HTTPS. NSSF supports 3gpp-Sbi-Target-Apiroot header for routing of Notification messages towards AMF. This support is provided by routing via SCP and providing URL info in 3gpp-Sbi-Target-Apiroot header.

References

Network Slice Selection Function (NSSF) Cloud Native Installation Guide

Acronyms and Terminology

The following table provides information about the acronyms used in the document:

Table 1-1 Acronyms

Field Description
5G-AN 5G Access Network
5GC 5G Core Network
5G-GUTI 5G Globally Unique Temporary Identifier
5QI 5G QoS Identifier
5G-S-TMSI 5G S-Temporary Mobile Subscription Identifier
5GS 5G System
5G-EIR 5G-Equipment Identity Register
(R)AN (Radio) Access Network
AMF Access and Mobility Management Function
AUSF Authentication Server Function
CAPIF Common API Framework for 3GPP northbound APIs
HTTPS Hypertext Transfer Protocol Secure
NEF Network Exposure Function
NF Network Function
NRF Network Repository Function
NSI ID Network Slice Instance Identifier
NSSAI Network Slice Selection Assistance Information
NSSF Network Slice Selection Function
Network Slice A logical network that provides specific network capabilities and network characteristics .
Network Slice instance A set of Network Function instances and the required resources (Example: compute, storage and networking resources) which form a deployed Network Slice.
NF service A functionality exposed by a NF through a service based interface and consumed by other authorized NFs.
NSSP Network Slice Selection Policy
PEI Permanent Equipment Identifier
PCF Policy Control Function
PLMN Public Land Mobile Network
QFI QoS Flow Identifier
QoE Quality of Experience
Requested NSSAI NSSAI provided by the UE to the Serving PLMN during registration.
Allowed NSSAI NSSAI provided by the Serving PLMN during a Registration procedure, indicating the S-NSSAIs values the UE could use in the Serving PLMN for the current registration area.
Configured NSSAI NSSAI provisioned in the UE applicable to one or more PLMNs.
SEPP Security Edge Protection Proxy
SBA Service Based Architecture
SBI Service Based Interface
SSC Session and Service Continuity
SSCMSP Session and Service Continuity Mode Selection Policy
SST Slice/Service type
SD Slice Differentiator
SMF Session Management Function
SMSF Short Message Service Function
S-NSSAI Single Network Slice Selection Assistance Information
TA Tracking Area
TAC Tracking Area Code
TAI Tracking Area Indentifier
UDM Unified Data Management
UDR Unified Data Repository
UDSF Unstructured Data Storage Function
UE User Equipment