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

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 can perform the task of OAuth validator for call scenarios to NS-Selection service and NS-Availability service.
  • OCNSSF can act 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}_{SigningAlgorithm}.pem" where nrfInstanceId is Instance Id of NRF and SigningAlgorithm 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 plaintext 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 {burstCapasity}/ {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