Embodiments described herein relate to methods and apparatuses to provide new type of analytic relative to tunneling traffic.
Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.
Some of the relevant architectural aspects for this disclosure are: the NWDAF (Network Data Analytics Function), the UDR (Unified Data Repository), the PCF (Policy Control Function), the SMF (Session Management Function), and the UPF (User Plane Function).
The NWDAF represents an operator managed network analytics logical function. The NWDAF is part of the 5GC architecture and uses the mechanisms and interfaces specified for 5GC and operations administration and management (OAM). The NWDAF interacts with different entities for different purposes. For example:
The Unified Data Repository (UDR) stores data grouped into distinct collections of subscription-related information:
The Policy Control Function (PCF) supports a unified policy framework to govern the network behavior. Specifically, the PCF provides PCC (Policy and Charging Control) rules to the PCEF (Policy and Charging Enforcement Function), i.e. the SMF/UPF that enforces policy and charging decisions according to provisioned PCC rules.
The Session Management function (SMF) supports different functionalities, e.g. the SMF may receive PCC rules from the PCF and configures the UPF accordingly.
The User Plane function (UPF) supports handling of user plane traffic based on the rules received from the SMF, e.g. packet inspection and different enforcement actions such as Quality of Service (QoS) handling.
In computer networks, a tunneling protocol is a communications protocol that allows for the movement of data from one network to another. It involves allowing private network communications to be sent across a public network (such as the Internet) through a process called encapsulation.
Tunneling is the idea of carrying lower-layer traffic in higher-layer (or equal-layer) packets. For example, IPv4 can be carried in an IPv4 or IPv6 packet; Ethernet can be carried in a User Datagram Protocol (UDP) or IPv4 or IPv6 packet, and so on.
In other words, tunneling is achieved by injecting packets into the payload of other packets.
Various protocols for establishing tunnels exist, e.g. Generic Routing Encapsulation (GRE) or the Layer 2 Tunneling Protocol (L2TP).
The result is that virtual links between computers in different networks may be set up. An example of this is a company's private network, which may be reached from the public network via tunneling.
Because tunneling involves repackaging the traffic data into a different form, it may hide the nature of the traffic that is run through a tunnel.
Users may also use tunneling to “sneak through” a firewall, using a protocol that the firewall would normally block, but “wrapped” inside a protocol that the firewall does not block, such as Domain Name System (DNS).
Types of tunneling techniques and protocols:
DNS tunneling is a difficult to detect attack that encodes the data of other programs or protocols in DNS queries and responses, by creating a covert communication channel that bypasses most firewalls. DNS tunneling enables cybercriminals to insert malware or pass stolen information into DNS queries. DNS requests are routed to the attacker's server, providing them with a covert command and control channel, and a data exfiltration path. DNS tunneling is also a technique use for fraud, as DNS traffic is usually free rated.
As an example, a user downloaded malware or an attacker exploited a vulnerability to deliver a malicious payload. If the attacker wants to maintain contact with the compromised device (to run commands on the victim device or exfiltrate data), they can establish a command-and-control (C&C) connection. C&C traffic may be required to pass through network perimeter defenses and evade detection while crossing the network.
DNS is a good candidate for establishing a tunnel, which is a cybersecurity term for a protocol connection that encapsulates a payload that contains data or commands and passes through perimeter defenses. Essentially, DNS tunneling hides data within DNS queries that are sent to an attacker-controlled server. DNS traffic is generally allowed to pass through perimeter defenses, such as firewalls, that typically block inbound and outbound malicious traffic.
To establish a DNS tunnel, the attacker registers a domain (adomain.com) and sets up a C&C server as the authoritative name server for adomain.com. The malware or payload on the compromised device sends a DNS query for a subdomain that represents an encoded communication (base64encodeddata.adomain.com). The query is eventually routed by a DNS resolver (through root and top-level domain servers) to the C&C server. The C&C server then sends a malicious DNS response that includes data (such as a command) to the compromised device, passing undetected through the perimeter. Over time, the attacker can continue C&C activity or exfiltrate data through the DNS tunnel.
An ICMP tunnel establishes a covert connection between two remote computers (a client and proxy), using ICMP echo requests and reply packets. An example of this technique is tunneling complete Transmission Control Protocol (TCP) traffic over ping requests and replies.
A virtual private network (VPN) extends a private network across a public network and enables users to send and receive data across shared or public networks as if their computing devices were directly connected to the private network. Applications running across a VPN may therefore benefit from the functionality, security, and management of the private network.
VPN systems may be classified by:
Tunnels are typically established through virtual private network (VPN) technologies. Once a VPN tunnel has been established between a teleworker's client device and the organization's VPN gateway, the teleworker can access many of the organization's computing resources through the tunnel.
The types of VPNs most commonly used for teleworkers are Internet Protocol Security (IPsec) and Secure Sockets Layer (SSL) tunnels. Tunneling may also be achieved by using Secure Shell (SSH), although this is less commonly used.
A mobile virtual private network (mobile VPN or mVPN) is a VPN which is capable of persisting during sessions across changes in physical connectivity, point of network attachment, and IP address. The “mobile” in the name refers to the fact that the VPN can change points of network attachment, not necessarily that the mVPN client is a mobile phone or that it is running on a wireless network.
Mobile VPNs are used in environments where workers need to keep application sessions open at all times, throughout the working day, as they connect via various wireless networks, encounter gaps in coverage, or suspend-and-resume their devices to preserve battery life. A conventional VPN may not be able to survive such events because the network tunnel is disrupted, causing applications to disconnect, time out, fail, or even the computing device itself to crash. Mobile VPNs are commonly used in public safety, home care, hospital settings, field service management, utilities and other industries. Increasingly, they are being adopted by mobile professionals and white-collar workers
Users utilize mobile virtual private networks (mobile VPN or mVPN) in settings where an endpoint of the VPN is not fixed to a single IP address, but instead roams across various networks such as data networks from cellular carriers or between multiple Wi-Fi access points without dropping the secure VPN session or losing application sessions. Mobile VPNs are widely used in public safety where they give law-enforcement officers access to applications such as computer-assisted dispatch and criminal databases, and in other organizations with similar requirements such as Field service management and healthcare.
Machine learning (ML) is the study of computer algorithms that improve automatically through experience. It is seen as a part of artificial intelligence. Machine learning algorithms build a model based on sample data, known as “training data”, in order to make predictions or decisions without being explicitly programmed to do so. Machine learning algorithms are used in a wide variety of applications, such as email filtering and computer vision, where it is difficult or unfeasible to develop conventional algorithms to perform the needed tasks.
There are 3 primary types of Machine Learning Algorithms:
According to some embodiments there is provided a method in a first network function, NF, in a network for providing, to a consumer NF, an analytic result relating to tunneling traffic. The method comprises receiving a request from the consumer NF, to receive analytics relating to tunneling traffic; responsive to receiving the request, triggering one or more network nodes to transmit data relating to tunneling traffic to the first NF; receiving data relating to tunneling traffic from one or more network nodes; analysing the received data to determine an analytic result; and transmitting an indication of the analytic result to the consumer NF.
According to some embodiments there is provided a method, in a consumer network function for receiving an analytic result relating to tunneling traffic from a first network function, NF. The method comprises transmitting a request to the first NF, to receive analytics relating to tunneling traffic; and receiving an indication of the analytic result from the first NF.
According to some embodiments there is provided a method in a User Plane Function, UPF, for providing data relating to tunneling traffic to a first network function, NF. The method comprises receiving a request from the first NF, to receive data relating to tunneling traffic; and responsive to detecting the tunneling traffic, providing data relating to the tunneling traffic to the first NF.
According to some embodiments there is provided a method in a wireless device, for providing data relating to tunneling traffic to a first network function, NF. The method comprises receiving a request from the first NF, wherein the request subscribes to receiving data relating to tunneling traffic; and responsive to detecting tunneling traffic, providing data relating to the tunneling traffic to the first NF.
According to some embodiments there is provided a method in a User Data Repository, UDR, for providing data relating to tunneling traffic to a first network function, NF. The method comprises receiving a request from the first NF, for data relating to tunneling traffic, wherein the request comprises an indication of at least one wireless device identification; and providing tunneling related subscriber data associated with the at least one wireless device identification to the first NF.
According to some embodiments there is provided a method in a first network function, NF, for training a ML model. The method comprises transmitting a request to a second network function and/or a wireless device to receive tagged data relating to tunneling traffic where the tagged data is tagged with a tag indicating a type of the tunneling traffic; receiving the tagged data relating to tunneling traffic from the second network function and/or the wireless device; and training the ML model based on the tagged data.
According to some embodiments there is provided a first network function, NF, in a network for providing, to a consumer NF, an analytic result relating to tunneling traffic. The first NF comprises processing circuitry configured to: receive a request from the consumer NF, to receive analytics relating to tunneling traffic; responsive to receiving the request, trigger one or more network nodes to transmit data relating to tunneling traffic to the first NF; receive data relating to tunneling traffic from one or more network nodes; analyse the received data to determine an analytic result; and transmit an indication of the analytic result to the consumer NF.
According to some embodiments there is provided a consumer network function for receiving an analytic result relating to tunneling traffic from a first network function, NF. The consumer network function comprises processing circuitry configured to: transmit a request to the first NF, to receive analytics relating to tunneling traffic; and receive an indication of the analytic result from the first NF.
According to some embodiments there is provided a User Plane Function, UPF, for providing data relating to tunneling traffic to a first network function, NF. The UPF comprises processing circuitry configured to: receive a request from the first NF, to receive data relating to tunneling traffic; and responsive to detecting the tunneling traffic, provide data relating to the tunneling traffic to the first NF.
According to some embodiments there is provided a wireless device, for providing data relating to tunneling traffic to a first network function, NF. The wireless device comprises processing circuitry configured to: receive a request from the first NF, wherein the request subscribes to receiving data relating to tunneling traffic; and responsive to detecting tunneling traffic, provide data relating to the tunneling traffic to the first NF.
According to some embodiments there is provided a User Data Repository, UDR, for providing data relating to tunneling traffic to a first network function, NF. The UDR comprises processing circuitry configured to: receive a request from the first NF, for data relating to tunneling traffic, wherein the request comprises an indication of at least one wireless device identification; and provide tunneling related subscriber data associated with the at least one wireless device identification to the first NF.
According to some embodiments there is provided first network function, NF, for training a ML model. The first NF comprises processing circuitry configured to: transmit a request to a second network function and/or a wireless device to receive tagged data relating to tunneling traffic where the tagged data is tagged with a tag indicating a type of the tunneling traffic; receive the tagged data relating to tunneling traffic from the second network function and/or the wireless device; and train the ML model based on the tagged data.
For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:
The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and/or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.
Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.
Tunneled traffic in mobile networks has increased significantly over the last years and is now becoming an important target for Mobile Network Operators (MNOs), which currently lack a proper mechanism to detect and control tunneled traffic. In addition to the above, and due to COVID-19, the number of mobile subscribers teleworking (using tunneled traffic through VPNs) has also increased significantly. Furthermore, traffic encryption trends make it more complex for a MNO to detect tunneled traffic.
Embodiments described herein propose methods and apparatuses that solve the above problems by utilizing a new type of analytic relative to tunneling traffic, which allows the mobile network operator (MNO) to detect tunneling (e.g. DNS tunneling, ICMP tunneling) and to act upon it.
One of the main objectives of a MNO is to control the traffic traversing MNO's network, specifically embodiments described herein, propose methods and apparatuses to perform statistical analysis on tunneling behavior, e.g. so as to improve MNO's data service contract and/or network performance.
In step 201 the method comprises receiving a request from the consumer NF, to receive analytics relating to tunneling traffic. The consumer NF may comprise any suitable NF, for example the PCF or OAM.
For example, the request may comprise a subscription request. The request may in some examples comprise one or more of: an indication of a tunneling traffic type, a list of one or more wireless device identifications, and an indication a tunneling scenario the first NF wishes to be alerted of.
For example, a tunneling traffic type may comprise one or more of: DNS, Internet Control Message Protocol (ICMP), Hypertext Transfer Protocol (HTTP), QUIC, Internet Protocol (IP) in IP, Generic Routing Encapsulation (GRE), Internet Protocol Security (IPSec), Layer 2 Tunneling Protocol (L2TP), Virtual Extensible LAN (VXLAN), Open Virtual Private Network (VPN), Secure Socket Tunneling Protocol (SSTP), Secure Shell (SSH), etc. The tunneling traffic type may indicate the specific tunneling protocol of interest for the consumer NF. When no specific tunneling traffic type is included in the request of step 201, the request may relate to tunneling analytics irrespective of the tunneling traffic type.
In step 202, the method comprises, responsive to receiving the request, triggering one or more network nodes to transmit data relating to tunneling traffic to the first NF.
The one or more network nodes may comprise one or more of: at least one user equipment, a User Plane Function, UPF, and a User Data Repository, UDR.
In step 203, the method comprises receiving data relating to tunneling traffic from the one or more network nodes.
In step 204, the method comprises analysing the received data to determine an analytic result. In some examples, step 204 may comprise performing statistical analysis of the received data. In some examples, step 204 may utilise a machine learning model to determine the analytic result.
The analytic result may comprise an indication of the tunneling traffic type. For example, the tunneling traffic type may comprise DNS, ICMP, HTTP, QUIC, IPinIP, GRE, IPSec, L2TP, VXLAN, OpenVPN, SSTP or SSH, etc.
The analytic result may comprise a list of wireless device identifications. The list of wireless device identifications may identify which wireless device IDs have been found to use tunneling (on a per tunneling protocol basis). Each wireless device ID may comprise a subscriber identifier (SUPI/IMSI), a subscriber public identifier (PUI/MSISDN) and/or a device identifier (PEI/IMEl).
The analytic result may comprise an indication of whether the tunneling traffic is considered normal or abnormal. For example, normal traffic may comprise a teleworker using a VPN tunnel towards his/her Enterprise, this is considered as normal behavior. However, when DNS protocol is used for tunneling traffic (e.g. DNS volume is much higher than normal), this may be considered abnormal behaviour. The indication of whether the tunneling traffic is considered normal or abnormal may be associated with a confidence level (e.g. a percentage from 0% to 100%).
The analytic result may in some examples comprise: an indication of a percentage of total traffic in the network that comprises tunneling traffic; an indication of a percentage of total traffic to and from a first wireless device that comprises tunneling traffic; and/or an indication of a percentage of total traffic that comprises tunneling traffic of a tunneling traffic type. This may be useful information, e.g. in case DNS tunneling is used for fraud, as DNS traffic is usually free of charge.
The analytic result may relate to the information contained in the request received in step 201. For example, if the request received in step 201 comprises an indication of a tunneling traffic type, then the analytic result may relate to tunneling traffic of the tunneling traffic type. Similarly, if the request received in step 201 comprises an indication of one or more wireless device identifications, the analytic result may relate to tunneling traffic to the one or more wireless devices identified by the one or more wireless device identifications. Similarly, if the request received in step 201 comprises an indication of a tunneling scenario (e.g. abnormal tunneling), then the analytic result may relate to tunneling traffic in said scenario.
In some examples, the analytic result comprises a list of one or more application identifications that are generating the tunneling traffic (e.g. App-ID=MyVPN).
In some examples, the analytic result may comprise one or more of: a list of one or more server addresses acting as tunnel endpoints for the tunneling traffic, and a list of one or more target domains for the tunneling traffic. The list of one or more target domains may Identify the target domain/s for the tunneling traffic, e.g. in case of HTTP tunneling, the domain included in the HTTP CONNECT request message; or in case of abnormal scenario with DNS tunneling, for a DNS query with QNAME including a subdomain that represents an encoded communication (base64encodeddata.adomain.com), the domain may be adomain.com.
In some examples, the analytic result comprises an indication of at least one recommended traffic management action.
For example, where the analytic result indicates that the tunneling traffic is abnormal the at least one recommended traffic management action may comprise one of: blocking tunneled traffic to one or more domains or server addresses, blocking tunneled traffic associated with one or more application identifications, and steering a copy of the tunneled traffic to an offline analytics engine.
For example, the recommended traffic action may be to block tunneled traffic to the suspect domains and/or Server addresses, or to block tunneled traffic for the suspect App-ID/s if the confidence level is high.
If the confidence level is medium the recommended traffic action may comprise traffic steering, for example, to steer a copy of the tunneled traffic towards an offline analytics engine.
In some examples, where the analytic result indicates that a majority of traffic to the first wireless device is tunneling traffic, and the recommended traffic management action comprises moving traffic of the first wireless device to a network slice suitable for tunneling traffic (e.g. from MBB slice into a VPN slice).
In some examples, the at least one recommended traffic management action comprises storing the analytic result as subscriber data at a user data repository. For example, for each suspect wireless device identification, an indication of the wireless device being a subscriber/device where tunneling has been detected and the corresponding tunneling information may be stored.
In step 205 the method comprises transmitting an indication of the analytic result to the consumer NF.
In step 301, the method comprises transmitting a request to the first NF, to receive analytics relating to tunneling traffic. Step 301 may correspond to step 201 of
For example, the request may comprise a subscription request. The request may in some examples comprise one or more of: an indication of a tunneling traffic type, a list of one or more wireless device identifications, and an indication a tunneling scenario the first NF wishes to be alerted of.
For example, a tunneling traffic type may comprise one or more of: DNS, ICMP, HTTP, QUIC, IPinIP, GRE, IPSec, L2TP, VXLAN, OpenVPN, SSTP, SSH, etc. The tunneling traffic type may indicate the specific tunneling protocol of interest for the consumer NF.
When no specific tunneling traffic type is included in the request of step 301, the request may relate to tunneling analytics irrespective of the tunneling traffic type.
In step 302, the method comprises receiving an indication of the analytic result from the first NF. Step 302 may correspond to step 205 of
The analytic result may comprise any suitable information as described previously with reference to
In some examples, the analytic result may comprise at least one recommended traffic management action. In these examples, the method of
In step 401, the method comprises receiving a request from the first NF, to receive data relating to tunneling traffic.
In step 402 the method comprises, responsive to detecting the tunneling traffic, providing data relating to the tunneling traffic to the first NF.
The request of step 401 may comprise an indication of a tunneling traffic type. In these examples, the detected tunneling traffic may therefore comprise tunneling traffic of the tunneling traffic type.
In some examples, the request of step 401 may comprise a list of one or more wireless device identifications. In these examples, the detected tunneling traffic may comprise tunneling traffic to or from a first wireless device identified by one of the one or more wireless devices identifications.
In some examples, the tunneling traffic comprises Domain Name System, DNS, tunneling traffic, and the data relating to the tunneling traffic comprises one or more of: a timestamp for a DNS query and/or a DNS answer, a volume of a DNS query and/or a DNS answer; a 5-tuple comprising a DNS server IP address; a DNS query type; a QNAME in DNS query type A/AAAA; a List of Server IP addresses in a DNS answer; raw Internet Protocol packets for the DNS tunneling traffic. It will be appreciated that other data may be provided.
In some examples, the tunneling traffic comprises Internet Protocol Security, IPSec, tunneling traffic, and the data relating to the tunneling traffic comprises one or more of: a timestamp for an IPSec event start time and/stop time; a volume of the IPSec tunneling traffic; an Internet Protocol, IP, Number associated with the IPSec tunneling traffic; an outer IP header source/destination IP address associated with the IPSec tunneling traffic; authentication header information; Encapsulating Security Payload header information. It will be appreciated that other data may be provided.
In some examples, the tunneling traffic comprises ICMP tunneling traffic (e.g. ICMP (IPv4) and ICMPv6), and the data relating to the tunneling traffic comprises one or more of: a timestamp for an ICMP flow start time and/or stop time; a 5-tuple a server IP address; a number of ICMP data packets in the flow; a volume of ICMP data packets in the flow (e.g. in bytes); a number of not usual Type (e.g. deprecated, experimental) data packets; a number of ICMP Echo Reply (Type 0) and Echo Request (Type 8) packets; a number of data packets with abnormal length; a number of data packets with abnormal content; a number of data packets with non-repetitive content; an average data packet length; a variance data packet length. It will be appreciated that other data may be provided.
In some examples, the tunneling traffic comprises HTTP or HTTPS tunneling traffic, and the data relating to the tunneling traffic comprises one or more of: for each detected HTTP/HTTPS flow: a timestamp for an HTTP/HTTPS flow start time and/or stop time; a TCP port (e.g. 80, 8080, 443); a volume (e.g. in bytes) of the HTTP/HTTPS flow; a 5-tuple comprising a HTTP/HTTPS server or proxy IP address; a number of HTTP CONNECT procedures; for each HTTP CONNECT message: a domain included in an HTTP CONNECT message; and/or for each successful response: a volume of traffic after an HTTP CONNECT procedure. It will be appreciated that other data may be provided.
In some examples, the tunneling traffic comprises QUIC tunneling traffic, and the data relating to the tunneling traffic comprises one or more of: for each detected QUIC flow: a timestamp for a QUIC flow start time and/or stop time; a UDP port (e.g. 80, 443); a volume (e.g. in bytes) of the QUIC flow; a 5-tuple comprising a QUIC server and/or proxy IP address; a number of CONNECT-UDP procedures; for each CONNECT-UDP message a domain included in CONNECT-UDP message; for each successful CONNECT-UDP response a volume of traffic after CONNECT-UDP procedure. It will be appreciated that other data may be provided.
In some examples, the tunneling traffic comprises IPinIP tunneling traffic, and the data relating to the tunneling traffic comprises one or more of: for each detected IPinIP flow: a timestamp fora IPinIP flow start time and/or stop time, a volume (e.g. in bytes) of the IPinIP flow; an outer IP header source/destination IP address; an inner IP header source/destination IP address; a type (e.g. IPv6 over IPv4, IPv4 over IPv4); and a protocol stack over IPinIP (e.g. TCP with TCP server port 80). It will be appreciated that other data may be provided.
In some examples, the tunneling traffic comprises GRE tunneling traffic, and the data relating to the tunneling traffic comprises one or more of: for each detected GRE flow: a timestamp for a GRE flow start time and/or stop time; a volume (e.g. in bytes) of the GRE flow; an IP Protocol Number (e.g. 47); an outer IP header source/destination IP address; and GRE encapsulated information (e.g. a network (e.g. IPv4/1Pv6, source/destination IP address); a transport (e.g. UDP/TCP, server port); and/or an upper protocol stack (e.g. TLS, QUIC, HTTP, and also other information like SNI)). It will be appreciated that other data may be provided.
In some examples, the tunneling traffic comprises L2TP tunneling traffic, and the data relating to the tunneling traffic comprises one or more of: for each detected L2TP flow: a timestamp for an L2TP flow start time and/or stop time; a volume (e.g. in bytes) of the L2TP flow; a transport port (e.g. 1701); an outer IP header source/destination IP address; an L2TP tunneling type (e.g. L2TP/IPsec); and L2TP packet information (e.g. Tunnel ID, Session ID). It will be appreciated that other data may be provided.
In some examples, the tunneling traffic comprises VXLAN tunneling traffic, and the data relating to the tunneling traffic comprises one or more of: for each detected VXLAN flow; a timestamp for a VXLAN flow start time and/or stop time; a volume (e.g. in bytes) of the VXLAN flow; a 5-tuple comprising a server IP address and UDP port (e.g. 4789); and VXLAN parameters (e.g. VNI or VXLAN Network Identifier). It will be appreciated that other data may be provided.
In some examples, the tunneling traffic comprises Open VPN tunneling traffic, and the data relating to the tunneling traffic comprises one or more of: for each detected
OpenVPN flow: a timestamp for an OpenVPN flow start time and/or stop time; a volume (e.g. in bytes) of the OpenVPN flow; a 5-tuple comprising a server IP address and a TCP port 1194. It will be appreciated that other data may be provided.
In some examples, the tunneling traffic comprises SSTP tunneling traffic, and the data relating to the tunneling traffic comprises one or more of: for each detected SSTP flow: a timestamp for a SSTP flow start time and/or stop time; a volume (e.g. in bytes) of the SSTP flow; a 5-tuple comprising a server IP address; SSTP packet information (e.g. Number of SSTP control packets, number of SSTP data packets, Message Type). It will be appreciated that other data may be provided.
In some examples, the tunneling traffic comprises SSH tunneling traffic, and data relating to the tunneling traffic comprises one or more of: for each detected SSH flow: a timestamp for a SSH flow start time and/or stop time; a volume (e.g. in bytes) of the SSH flow; a transport port (e.g. 22); a 5-tuple comprising an SSH server/proxy IP address. It will be appreciated that other data may be provided.
Alternatively, the UPF might report raw data (e.g. raw DNS packets of the tunneling traffic type is DNS)
In step 501 the method comprises receiving a request from the first NF, wherein the request subscribes to receiving data relating to tunneling traffic.
In step 502 the method comprises, responsive to detecting tunneling traffic, providing data relating to the tunneling traffic to the first NF.
In some examples, the request in step 501 comprises an indication of a tunneling traffic type, In these examples, the detected tunneling traffic comprises tunneling traffic of the tunneling traffic type.
In some examples, the tunneling traffic comprises Domain Name System, DNS, tunneling and wherein the data relating to the tunneling traffic comprises one or more of: an indication of whether the tunneling traffic was triggered by a DNS stub resolver at the Operating System, OS, (e.g. Android) of a wireless device or at an application client (e.g. .browsers usually include their own DNS stub resolver); an application identification, ID, indicating which application client triggered the DNS tunneling traffic;
a timestamp for a DNS query and/or a DNS answer; a volume (e.g. in bytes) of a DNS query and/or a DNS answer; a 5-tuple comprising a DNS server IP address; a DNS query type (e.g. A/AAAA); a QNAME in DNS query type A/AAAA; a list of server IP addresses in a DNS answer.
In some examples, the tunneling traffic comprises Internet Protocol Security, IPSec, ICMP, HTTP, QUIC, IPinIP, GRE, IPSec, L2TP, VXLAN, OpenVPN, SSTP or SSH, HTTP, QUIC, IPinIP, GRE, L2TP, VXLAN, OpenVPN, SSTP or SSH tunneling traffic and wherein the data relating to the tunneling traffic comprises one or more of: an application identification, App-ID, indicating which application client triggered the tunneling traffic; a timestamp for a start and/or a stop of the tunneling traffic; a number of packets in the tunneling traffic; a volume of packets in the tunneling traffic; a 5-tuple associated with the tunneling traffic comprising a server IP address.
In step 601, the method comprises receiving a request from the first NF, for data relating to tunneling traffic, wherein the request comprises an indication of at least one wireless device identification. The first NF may be configured to perform the method as described with reference to
In step 602, the method comprises providing tunneling related subscriber data associated with the at least one wireless device identification to the first NF.
In other words, the UDR may be configured to retrieve subscriber data (specifically historic Tunneling related information for this subscriber).
In step 751 the method comprises transmitting a request to a second network function and/or a wireless device to receive tagged data relating to tunneling traffic, wherein the request includes an indication to tag the data with the type of the tunneling traffic. The second network function may comprise a UPF.
In step 751, the method comprises receiving the tagged data relating to tunneling traffic from the second network function and/or the wireless device, wherein the tagged data includes a tag indicating the type of the tunneling traffic.
In step 753, the method comprises training the ML model based on the tagged data.
In step 701, a consumer NF (any NF, e.g. OAM) subscribes to the NWDAF to trigger the training process relative to a new analytic (Analytic-ID=Tunneling), by transmitting a Nnwdaf_Training_Subscribe request message. The Nnwdaf_Training_Subscribe request message may comprise one or more of the following parameters:
In step 702, the NWDAF responds to the request of step 701 with a successful response (accepting the request).
In step 703, the NWDAF triggers data collection from UPF, specifically to retrieve information relative to DNS traffic detected by UPF for UE-ID. In order to do this, NWDAF transmits a Nupf_EventExposure_Subscribe request message to the UPF. The Nupf_EventExposure_Subscribe message may comprise one or more of the following parameters:
It will be appreciated that, for example, the existing mechanisms proposed in 3GPP TR 23.700-91 (e.g. through SMF or directly, assuming a service based UPF) may be used for the NWDAF triggering data collection from the UPF.
In step 704, the UPF responds to the request message in Step 703 with a successful response (accepting the request).
In step 705, the NWDAF triggers data collection from UE, specifically to retrieve information relative to DNS traffic for UE-ID. In order to do this, NWDAF triggers an Nue_EventExposure_Subscribe request message. The Nue_EventExposure_Subscribe request message may comprise one or more of the following parameters:
It will be appreciated that, for example, the existing mechanisms proposed in 3GPP TR 23.700-91 may be used for the NWDAF to trigger data collection from the UE.
In step 706, UE responds to the request message in 705 with a successful response (accepting the request).
In step 707, the UE triggers DNS tunneling traffic (In this example, a DNS query transmitted to the UPF in step 708) and marks it with Tag-ID. The UE detects the DNS tunneling traffic and gathers data for Event-ID=DNSTraffic. Specifically, the UE may store the following information:
In step 709 the UPF detects the uplink DNS traffic (the DNS query transmitted to the DNS resolver in step 710), which in this case is marked with Tag-ID and gathers data for Event-ID=DNSTraffic. Specifically, UPF stores the following information:
In step 711, the DNS Resolver looks for the Authoritative DNS Server for adomain.com. In step 712, the DNS Resolver transmits the DNS query to the Authoritative DNS Server.
In this example, the Authoritative DNS Server is Malicious and so in step 713, the (Malicious) Authoritative DNS Server (adomain.com) retrieves the covert data in QNAME (base64encodeddata).
In step 714, the Authoritative DNS Server answers the DNS Query with command and control data in DNS answer.
In step 715 the DNS Answer is forwarded to the UPF by the DNS Resolver.
In step 716, the UPF detects downlink DNS traffic and gathers data for Event-ID=DNSTraffic.
In step 717, the UPF forwards the DNS answer to the UE.
In step 718, the UE continues gathering data for Event-ID=DNSTraffic and at some point (e.g. periodic reporting), UE reports data for Event-ID=DNSTraffic. In order to do that, UE notifies NWDAF in step 719 by triggering a Nue_EventExposure_Notify request message. The Nue_EventExposure_Notify request message may comprise one or more of the following parameters:
In step 720, the NWDAF answers the message in step 719 with a successful response.
In step 721, the UPF continues gathering data for Event-ID=DNSTraffic and at some point (e.g. periodic reporting), UPF reports data for Event-ID=DNSTraffic. In order to do that, UPF notifies NWDAF by transmitting, in step 722, a Nupf_EventExposure_Notify request message. The Nupf_EventExposure_Notify request message may comprise one or more of the following parameters:
In step 723, the NWDAF answers the message in Step 722 with a successful response.
In step 724, the UE triggers regular DNS traffic. UE detects it and gathers data for Event-ID=DNSTraffic. Specifically, the UE may store one or more of the following information:
In step 725, the UE transmits the DNS query to the UPF.
In step 726, the UPF detects uplink DNS traffic, which in this case is not marked with Tag-ID, and gathers data for Event-ID=DNSTraffic. Specifically, UPF may store one or more of the following information:
In step 727, the UPF forwards the DNS query to the DNS Resolver. In step 728 and 729, the DNS Resolver answers the DNS query (e.g. it has cached the entry).
In step 730, the UPF detects downlink DNS traffic and gathers data for Event-ID=DNSTraffic. In step 731, the UPF forwards the DNS answer to the UE.
In step 732, the UE continues gathering data for Event-ID=DNSTraffic and at some point (e.g. periodic reporting), UE reports data for Event-ID=DNSTraffic. In order to do that, the UE may notify NWDAF by transmitting, in step 733, a Nue_EventExposure_Notify request message. The Nue_EventExposure_Notify request message may comprise one or more of the following parameters:
In step 734, the NWDAF answers the message in step 733 with a successful response.
In step 735, the UPF continues gathering data for Event-ID=DNSTraffic and at some point (e.g. periodic reporting), the UPF reports data for Event-ID=DNSTraffic. In order to do that, UPF may notify NWDAF by transmitting in step 736 a Nupf_EventExposure_Notify request message. The Nupf_EventExposure_Notify request message may comprise one or more of the following parameters:
In step 737, the NWDAF answers the message in step 736 with a successful response.
In step 738, the NWDAF trains the ML model based on the data collected (tagged and untagged). The resulting ML model can be obtained through supervised ML algorithms such as decision tree, random forest, regression, etc. In step 739, the NWDAF may notify the consumer NF that the training process has finished by triggering a Nnwdaf_Training_Notify request message indicating successful operation.
In step 740, the Consumer NF answers the message in step 739 with a successful response.
To exemplify the embodiments described above in
In step 801, a consumer NF (e.g. any suitable NF, e.g. PCF or OAM) subscribes to the NWDAF to receive an analytic result relating to tunneling traffic (Analytic-ID=Tunneling). This may be done by transmitting a Nnwdaf_AnalyticsSubscription_Subscribe request message to the NWDAF. The Nnwdaf_AnalyticsSubscription_Subscribe request message may comprise one or more of the following parameters:
In step 802, the NWDAF answers the request message in step 801 with a successful response (accepting the request).
In step 803, the NWDAF triggers data collection from UDR. In order to do this, NWDAF may request the UDR for the subscriber data relative to the UE-ID received in step 801. In order to do this, the NWDAF may transmit an Nudr_Query request message to the UDR indicating UE-ID as parameter.
In step 804, the UDR returns the subscriber data for UE-ID, for example, comprising historic DNS tunneling related information for UE-ID.
In step 805, the NWDAF triggers data collection from UPF, specifically to retrieve information relative to DNS traffic detected by UPF for UE-ID. In order to do this, the NWDAF may transmit a Nupf_EventExposure_Subscribe request message to the UPF. The Nupf_EventExposure_Subscribe request message may comprise one or more of the following parameters:
It will be appreciated that, for example, the existing mechanisms proposed in 3GPP TR 23.700-91 may be used (e.g. through SMF or directly, assuming a service based UPF) for the NWDAF to trigger data collection from the UPF.
In step 806, the UPF answers the request message in step 805 with a successful response (accepting the request). appropriate
In step 807, the NWDAF triggers data collection from the UE, specifically to retrieve information relative to DNS traffic for UE-ID. In order to do this, NWDAF may transmit a Nue_EventExposure_Subscribe request message to the UE. The Nue_EventExposure_Subscribe request message may comprise one or more of the following parameters:
It will be appreciated that, for example, the existing mechanisms proposed in 3GPP TR 23.700-91 may be used for the NWDAF to trigger data collection from the UE.
In step 808, the UE answers the request message in step 807 with a successful response (accepting the request).
In step 809, a User of the UE starts an application (App-ID=example). The UE detects the starting of the application and gathers data for Event-ID=DNSTraffic. Specifically, UE may store one or more of the following information:
In step 810, the UE transmits a DNS query to the UPF.
In step 811, the UPF detects the uplink DNS traffic and gathers data for Event-ID=DNSTraffic. Specifically, the UPF may store one or more of the following information:
In step 812, the UPF forwards the DNS query to a DNS Resolver.
In step 813, the DNS Resolver looks for the Authoritative DNS Server for adomain.com.
In step 814, the DNS Resolver forwards the DNS query to the Authoritative DNS Server.
In step 815, the (Malicious) Authoritative DNS Resolver (adomain.com) retrieves the covert data in QNAME (base64encodeddata) and in step 816 answers with command and control data in a DNS answer to the DNS Resolver.
In step 817, the DNS Resolver forwards the DNS answer to the UPF.
In step 818, the UPF detects downlink DNS traffic and gathers data for Event-ID=DNSTraffic.
In step 819, the UPF forwards the DNS answer to the UE.
In step 820, the UE continues gathering data for Event-ID=DNSTraffic and at some point (e.g. periodic reporting), UE reports data for Event-ID=DNSTraffic. In order to do that, UE may notify NWDAF by transmitting in step 821 a Nue_EventExposure_Notify request message. The Nue_EventExposure_Notify request message may comprise one or more of the following parameters:
In step 822, the NWDAF answers the message in step 821 with a successful response.
In step 823, the UPF continues gathering data for Event-ID=DNSTraffic and at some point (e.g. periodic reporting), the UPF reports data for Event-ID=DNSTraffic. In order to do that, the UPF may notify the NWDAF by transmitting in step 824 a Nupf_EventExposure_Notify request message. The Nupf_EventExposure_Notify request message may comprise one or more of the following parameters:
In step 825, the NWDAF answers the message in step 824 with a successful response.
In step 826, the NWDAF determines an analytic result based on the data collected from one or more of the UDR, UE and UPF. To detect DNS tunneling, in this example, the NWDAF uses a Machine Learning model (which may, for example, be obtained through the training process described in
Additionally (or alternatively), the NWDAF may search for unexpected or uncorrelated DNS data that is indicative of DNS tunneling. As an example, the NWDAF might analyze both timestamps and volume, in case there is an unusually large number of DNS queries for a single domain (adomain.com) and each query includes e.g. a unique subdomain of arbitrary data (base64encodeddata). If the NWDAF does determine that there is an unusually large number of DNS queries for a single domain (adomain.com) and each query includes e.g. a unique subdomain of arbitrary data (base64encodeddata) the NWDAF may determine that DNS tunneling is happening and may store one or more of the following information:
In step 827, the NWDAF may transmit an analytic result to the Consumer NF. For example, the NWDAF may transmit a Nnwdaf_AnalyticsSubscription_Notify request message. The Nnwdaf_AnalyticsSubscription_Notify request message may comprise one or more of the following parameters:
In step 828, the consumer NF answers the message in step 827 with a successful response.
In step 829, in this example, the consumer NF applies the corresponding recommended traffic management action(s) based on the AnalyticResult. In this example, the consumer NF to store in the subscriber data an indication of being a subscriber/device where DNS tunneling has been detected and the corresponding DNS tunneling information) In order to do this, the consumer NF transmits, in step 830 towards the UDR a
Nudr_Store request message. The Nudr_Store request message may comprise one or more of the following parameters:
In step 831, the UDR stores the TunnelingInfo in the subscriber data for UE-ID.
In step 832, the UDR answers the message in step 830 with a successful response.
Whilst it is not illustrated in
The TunnelingInfo stored in the UDR may be used in subsequent sessions for UE-ID, e.g. to continue monitoring Tunneling for UE-ID and, if the same behavior is found and/or if the accumulated suspect Tunneled volume exceeds a configured threshold, the user may be notified accordingly.
In step 805, the NWDAF triggers data collection from UPF, specifically to retrieve information relative to DNS traffic detected by UPF for UE-ID. In order to do this, NWDAF triggers a Nupf_EventExposure_Subscribe request message including the following parameters:
In step 811, the UPF detects uplink DNS traffic and gathers data for Event-ID=DNSRawTraffic. Specifically, UPF stores the following information:
In step 818, the UPF detects downlink DNS traffic and gathers data for Event-ID=DNSRawTraffic.
In step 823, the UPF continues gathering data for Event-ID=DNSRawTraffic and at some point (e.g. periodic reporting), UPF reports data for Event-ID=DNSRawTraffic. In order to do that, the UPF may notify the NWDAF by transmitting in step 824 Nupf_EventExposure_Notify request message. The Nupf_EventExposure_Notify request message may comprise the following parameters:
In step 1001, a consumer NF (any suitable NF, e.g. PCF or OAM) subscribes to the NWDAF to receive an analytic result relating to tunneling traffic (Analytic-ID=Tunneling). For example, the consumer NF may transmit a Nnwdaf_AnalyticsSubscription_Subscribe request message to the NSDAF. The Nnwdaf_AnalyticsSubscription_Subscribe request message may comprise one or more of the following parameters:
In step 1002, the NWDAF answers the request message in step 1001 with a successful response (accepting the request).
In step 1003, the NWDAF triggers data collection from UDR. For example, the NWDAF requests UDR for the subscriber data relative to UE-ID. In order to do this, the NWDAF may transmit a Nudr_Query request message indicating UE-ID as parameter.
In step 1004, the UDR returns the subscriber data for UE-ID, for example, comprising historic IPSec tunneling related information for UE-ID.
In step 1005, the NWDAF triggers data collection from the UPF, specifically to retrieve information relative to IPSec traffic detected by UPF for UE-ID. In order to do this, the NWDAF may transmit a Nupf_EventExposure_Subscribe request message. The Nupf_EventExposure_Subscribe request message may comprise one or more of the following parameters:
It will be appreciated that the existing mechanisms proposed in 3GPP TR 23.700-91 may be used (e.g. through SMF or directly, assuming a service based UPF) for the NWDAF to trigger data collection from the UPF.
In step 1006, the UPF answers the request message in step 1005 with a successful response (accepting the request).
In step 1007, the NWDAF triggers data collection from the UE, specifically to retrieve information relative to IPSec traffic for UE-ID. In order to do this, the NWDAF may transmit a Nue_EventExposure_Subscribe request message. The Nue_EventExposure_Subscribe request message may comprise one or more of the following parameters:
It will be appreciated that the existing mechanisms proposed in 3GPP TR 23.700-91 may be used for the NWDAF to trigger data collection from the UE.
In step 1008, the UE answers the request message in step 1007 with a successful response (accepting the request).
In step 1009, the User of the UE starts application (App-ID=example). The application client triggers IPSec traffic towards the Server (Tunnel endpoint). The UE detects the IPSec traffic and gathers data for Event-ID=IPSecTraffic. Specifically, the UE may store one or more of the following information:
In step 1010, the UE transmits the IPSec traffic to the UPF.
In step 1011, the UPF detects the uplink IPSec traffic and gathers data for Event-ID=IPSecTraffic. Specifically, the UPF may store one of more of the following information:
In step 1012, the UPF forwards the IPSec traffic to the IPSec tunnel endpoint.
In step 1013, IPSec tunnel endpoint transmits IPSec traffic to the UPF.
In step 1014, the UPF detects downlink IPSec traffic and gathers data for Event-ID=IPSecTraffic.
In step 1015, the UPF forwards the IPSec traffic to the UE.
In step 1016, the UE continues gathering data for Event-ID=IPSecTraffic and at some point (e.g. periodic reporting), UE reports data for Event-ID=IPSecTraffic. In order to do that, the UE may notify the NWDAF by transmitting, in step 1017, a Nue_EventExposure_Notify request message. The Nue_EventExposure_Notify request message may comprise one or more of the following parameters:
In step 1018, the NWDAF answers the message in step 1017 with a successful response.
In step 1019, the UPF continues gathering data for Event-ID=IPSecTraffic and at some point (e.g. periodic reporting), UPF reports data for Event-ID=IPSecTraffic. In order to do that, the UPF may notify the NWDAF by transmitting in step 1020 a Nupf_EventExposure_Notify request message. The Nupf_EventExposure_Notify request message may comprise one or more of the following parameters:
In step 1021, the NWDAF answers the message in step 1020 with a successful response.
In step 1022, the NWDAF determines an analytic result based on the data collected from UDR, UE and UPF. To detect VPN traffic, the NWDAF, in this example, uses a Machine Learning model (which may be obtained through a training process similar to the one described in
In step 1023, the NWDAF notifies the Consumer NF (e.g. PCF) by transmitting a Nnwdaf_AnalyticsSubscription_Notify request message. The Nnwdaf_AnalyticsSubscription_Notify request message may comprise one or more of the following parameters:
In step 1024, the consumer NF (e.g. PCF) answers the message in step 1023 with a successful response.
In step 1025, the consumer NF (e.g. PCF) initiates performance of the at least one recommended traffic management action based on the AnalyticResult, e.g. the consumer NF may request slice re-selection by moving the UE-ID session from existing slice (e.g. MBB) to another slice (Tunneling slice). In some examples, the consumer NF may indicate the reason for moving (e.g. VPN or IPSec tunneling), and the consumer NF may store tunneling information in the UDR.
In step 1026, the consumer NF (e.g. PCF) stores in the UDR an indication of a subscriber/device (e.g. the UE) where IPSec tunneling has been detected and the corresponding IPSec tunneling information. In order to do this, the consumer NR may transmit towards the UDR a Nudr_Store request message. The Nudr_Store request message comprises one or more of the following parameters:
In step 1027, the UDR stores the TunnelingInfo in the subscriber data for UE-ID.
In step 1028, the UDR answers the message in step 1027 with a successful response.
Whilst it is not illustrated in
It will be appreciated that whilst in the above description the function of the NWDAF is described as being performed by a separate entity, the NWDAF may be co-located with another entity, such as the UPF.
Briefly, the processing circuitry 1101 of the first NF 1100 is configured to: receive a request from the consumer NF, to receive analytics relating to tunneling traffic; responsive to receiving the request, trigger one or more network nodes to transmit data relating to tunneling traffic to the first NF; receive data relating to tunneling traffic from one or more network nodes; analyse the received data to determine an analytic result; and transmit an indication of the analytic result to the consumer NF.
In some embodiments, the first NF 1100 may optionally comprise a communications interface 1102. The communications interface 1102 of the first NF 1100 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1102 of the first NF 1100 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1101 of first NF 1100 may be configured to control the communications interface 1102 of the first NF 1100 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
Optionally, the first NF 1100 may comprise a memory 1103. In some embodiments, the memory 1103 of the first NF 1100 can be configured to store program code that can be executed by the processing circuitry 1101 of the first NF 1100 to perform the method described herein in relation to the first NF 1100. Alternatively, or in addition, the memory 1103 of the first NF 1100, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1101 of the first NF 1100 may be configured to control the memory 1103 of the first NF 1100 to store any requests, resources, information, data, signals, or similar that are described herein.
Briefly, the processing circuitry 1201 of the consumer NF 1200 is configured to: transmit a request to the first NF, to receive analytics relating to tunneling traffic; and receive an indication of the analytic result from the first NF.
In some embodiments, the consumer NF 1200 may optionally comprise a communications interface 1202. The communications interface 1202 of the consumer NF 1200 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1202 of the consumer NF 1200 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1201 of consumer NF 1200 may be configured to control the communications interface 1202 of the consumer NF 1200 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
Optionally, the consumer NF 1200 may comprise a memory 1203. In some embodiments, the memory 1203 of the consumer NF 1200 can be configured to store program code that can be executed by the processing circuitry 1201 of the consumer NF 1200 to perform the method described herein in relation to the consumer NF 1200. Alternatively, or in addition, the memory 1203 of the consumer NF 1200, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1201 of the consumer NF 1200 may be configured to control the memory 1203 of the consumer NF 1200 to store any requests, resources, information, data, signals, or similar that are described herein.
Briefly, the processing circuitry 1301 of the UPF 1300 is configured to: receive a request from the first NF, to receive data relating to tunneling traffic; and responsive to detecting the tunneling traffic, provide data relating to the tunneling traffic to the first NF.
In some embodiments, the UPF 1300 may optionally comprise a communications interface 1302. The communications interface 1302 of the UPF 1300 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1302 of the UPF 1300 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1301 of UPF 1300 may be configured to control the communications interface 1302 of the UPF 1300 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
Optionally, the UPF 1300 may comprise a memory 1303. In some embodiments, the memory 1303 of the UPF 1300 can be configured to store program code that can be executed by the processing circuitry 1301 of the UPF 1300 to perform the method described herein in relation to the UPF 1300. Alternatively, or in addition, the memory 1303 of the UPF 1300, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1301 of the UPF 1300 may be configured to control the memory 1303 of the UPF 1300 to store any requests, resources, information, data, signals, or similar that are described herein.
Briefly, the processing circuitry 1401 of the wireless device 1400 is configured to: receive a request from the first NF, wherein the request subscribes to receiving data relating to tunneling traffic; and responsive to detecting tunneling traffic, provide data relating to the tunneling traffic to the first NF.
In some embodiments, the wireless device 1400 may optionally comprise a communications interface 1402. The communications interface 1402 of the wireless device 1400 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1402 of the wireless device 1400 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1401 of wireless device 1400 may be configured to control the communications interface 1402 of the wireless device 1400 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
Optionally, the wireless device 1400 may comprise a memory 1403. In some embodiments, the memory 1403 of the wireless device 1400 can be configured to store program code that can be executed by the processing circuitry 1401 of the wireless device 1400 to perform the method described herein in relation to the wireless device 1400. Alternatively, or in addition, the memory 1403 of the wireless device 1400, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1401 of the wireless device 1400 may be configured to control the memory 1403 of the wireless device 1400 to store any requests, resources, information, data, signals, or similar that are described herein.
Briefly, the processing circuitry 1501 of the UDR 1500 is configured to: receive a request from the first NF, for data relating to tunneling traffic, wherein the request comprises an indication of at least one wireless device identification; and provide tunneling related subscriber data associated with the at least one wireless device identification to the first NF.
In some embodiments, the UDR 1500 may optionally comprise a communications interface 1502. The communications interface 1502 of the UDR 1500 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1502 of the UDR 1500 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1501 of UDR 1500 may be configured to control the communications interface 1502 of the UDR 1500 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
Optionally, the UDR 1500 may comprise a memory 1503. In some embodiments, the memory 1503 of the UDR 1500 can be configured to store program code that can be executed by the processing circuitry 1501 of the UDR 1500 to perform the method described herein in relation to the UDR 1500. Alternatively, or in addition, the memory 1503 of the UDR 1500, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1501 of the UDR 1500 may be configured to control the memory 1503 of the UDR 1500 to store any requests, resources, information, data, signals, or similar that are described herein.
Embodiments described herein allow the network operator to support detection and control (e.g. traffic management, security attacks prevention, fraud prevention, etc) of different tunneling scenarios in a simple an efficient way, by identifying the amount and types of tunneled traffic in MNO's network, and which subscribers, devices, domains, applications and servers are responsible for it.
For example, if the tunneling traffic in MNO's network represents e.g. 15% of the total traffic (determined by the methods described above), this may be considered to be a significant amount, and gives a hint to MNO on the need to control this traffic (by taking actions). Additionally, from the 15% above, consider if IP in IP is 6%, GRE is 4%, IPSec is 3%. This (global) information may be useful for the MNO to take the corresponding decisions (e.g. to improve MNO's data service contract, allowing enterprises and/or individual subscribers to use VPNs within MNO's network, by creating a specific VPN bundle with an extra charge on top of the general Internet bundle). Additionally, the methods and apparatuses described above allow for identifying which subscribers use tunneling protocols in their sessions, so they can be offered accordingly on a per individual basis.
In another example, similarly to above the tunneling traffic represents 15% of the total traffic in MNO network, which is a significant amount, but in this example, by using the methods and apparatuses described above, it is determined that 13% of this traffic is from Enterprises, Industrial and/or IoT devices which connect by default to the Enterprise or Industrial network (through MNO's network) using tunneling protocols. In this example, individual subscribers' contribution to the total traffic is only 2%, which gives a hint to MNO not to take any specific action.
Embodiments described herein allows the MNO to detect tunneled traffic for VPNs, e.g. teleworkers, and the traffic management action might be e.g. moving teleworkers into a separate slice (i.e. separate from the MBB slice).
Embodiments described herein also allow the MNO to differentiate between “normal” tunneling scenarios (e.g. an MNO's subscriber doing teleworking) and malicious tunneling scenarios (e.g. fraud, security related attacks). For example, a teleworker would most probably have almost 100% of his/her traffic tunneled, while in a fraud/security scenario, the tunneled traffic would probably be a much smaller % (imagine tunneling only applies to a specific application, and the rest of traffic is regular traffic, not tunneled, for the rest of applications).
It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.
Number | Date | Country | Kind |
---|---|---|---|
21382246.3 | Mar 2021 | EP | regional |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2021/072856 | 8/17/2021 | WO |