WO2018219455A1

WO2018219455A1 - Management of encrypted network traffic

Info

Publication number: WO2018219455A1
Application number: PCT/EP2017/063223
Authority: WO
Inventors: Franco Foresti; Ibon Gochi Garcia; Miguel Angel MUÑOZ DE LA TORRE ALONSO
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2017-05-31
Filing date: 2017-05-31
Publication date: 2018-12-06

Abstract

A network node (200) and associated method for use as a Policy Control Enforcement Function, PCEF, (102) or a Traffic Detection Function, TDF, (104) for managing Internet Protocol, IP, traffic in a telecommunications network, the network node comprising: a receiver (204) configured to receive a session establishment message from a User Equipment, UE, the session establishment message for establishing a session between the UE and a web server hosting a URL which the UE requests; an extractor (214) configured to extract from the session establishment message data indicative of the requested URL; and a query manager (216) configured to generate a query based on the extracted data and to control a transmitter (202) to transmit the generated query to a further network node configured to provide policy data specifying how IP traffic between a UE and the web server should be managed, wherein the receiver is further configured to receive, from the further network node, policy data relating to the requested URL and for use in management of subsequent IP traffic between the UE and the web server hosting the requested URL.

Description

MANAGEMENT OF ENCRYPTED NETWORK TRAFFIC Technical field The invention relates to management of traffic in a telecommunications network, wherein management of traffic comprises content filtering and/or redirection. More specifically, the invention may relate to management of encrypted traffic in a telecommunications network. Background

The Policy and Charging Control (PCC) architecture of the Third Generation Partnership Project (3GPP) permits the integration of both policy and charging control within a telecommunications network.

The PCC architecture is depicted in Figure 1 , which has been taken from TS 23.203 V14.3.0, which specifies the PCC functionality for the Evolved 3GPP Packet Switched domain, including both 3GPP accesses and non-3GPP access. Exemplary 3GPP accesses include: Global System for Mobile Communications (GSM) Enhanced Data- rates for Global Evolution (EDGE) Radio Access Network (GERAN); Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN); Evolved UTRAN (E-UTRAN).

Some elements of the PCC architecture of Figure 1 are discussed briefly below. In any event, the function of each of the elements of Figure 1 will be known to the skilled person.

• A Policy and Charging Rules Function (PCRF) 100 is a functional element that performs policy control decision and flow based charging control. The PCRF 100 provides network control regarding the service data flow detection, gating, quality of service (QoS) and flow based charging (except credit management) towards a Policy Control Enforcement Function (PCEF) 102. • The PCEF 102 encompasses service data flow detection, policy enforcement and flow based charging functionalities. Deep Packet Inspection (DPI) technology, which may be embedded in the PCEF 102, is configured to inspect and/or analyze the contents of Internet Protocol (IP) data packets beyond the so called IP 5-tuples. The IP 5-tuples comprise the heading elements of an IP data packet, i.e. IP source address, IP destination address, source transport address, destination transport address, and protocol over IP (e.g. Transmission Control Protocol (TCP) or User Data Protocol (UDP)). Therefore, DPI technology comprises inspecting and/or analyzing application layer information conveyed by IP data packets. As a result of DPI analysis, service classification information can be obtained, which allows IP packets to be classified according to a configured tree of rules so that they are assigned to a particular service session.

• A Traffic Detection Function (TDF) 104 comprises a DPI function that has been standardized in 3GPP Release 1 1 . The TDF 104 provides DPI in a stand-alone entity.

• The Sd reference point 106 is defined in 3GPP TS 29.212 V14.3.0 and lies between the PCRF 100 and the TDF 104.

• The Gx reference point 108 is defined in 3GPP TS 29.212 V14.3.0 and lies between the PCRF 100 and the PCEF 102.

• The Subscription Profile Repository (SPR) 1 10 is a logical entity that contains subscriber/subscription related information needed for subscription-based policies and Internet Protocol Connectivity Access Network (IP-CAN) bearer level PCC rules by the PCRF 100.

Network Operators provide different Traffic Management services to their subscribers including e.g. traffic redirection and content filtering.

Traffic redirection redirects to a particular location IP traffic that is not permissible under a user's subscription information. For example, if a user attempts to access a Uniform Resource Locator (URL) that is blocked or that the user is otherwise not allowed to access then the user may be redirected to another URL explaining that accessing the requested URL is not possible. This allows the operator to keep the user informed of any reasons that lead to a redirection e.g. access restrictions, insufficient data quota or a parental control. Content filtering may be provided for Wireless Access Protocol (WAP) and Internet services (e.g. Hypertext Transfer Protocol 1 .X (HTTP/1 .X) and HTTP/2) with the help of an external content classification engine, which is also known as a content categorization engine. Content filtering may be legally required in certain countries and may also be implemented for reasons such as parental control, corporate black and white lists and/or censorship. The content filtering functionality is enabled based on the subscriber^'s profile in the SPR 1 10. In exemplary systems, when a user request for access to a particular URL arrives, the PCEF 102 or TDF 104 extracts the URL from the user request using DPI. The DPI engine will typically detect a HTTP request message coming from the UE (e.g. a certain HTTP method like HTTP GET), and will then parse and extract the Request- URI field from that HTTP request message. The PCEF 102 or TDF 104 then transmits the extracted URL as part of an Internet Content Application Protocol (ICAP) query to an external content classification engine. The external content classification engine contains a URL database that is regularly updated to track changes in the internet content. The external content classification engine determines a content category for the URL and transmits the content category to the PCEF 102 or TDF 104. For the sake of simplicity, the external content classification engine may further be referred to as an ICAP server.

The content categories received from the ICAP/content classification engine server are used to determine specific actions for content filtering. A local policy determines whether an IP packet must be allowed, blocked, or redirected based on the content category. As mentioned above, redirection allows the operator to keep the user informed of the reasons that lead to any access restrictions. In addition, the redirection can also present the user with a method of authentication so that the user can access the content on the spot (for example, by using a Personal Identification Number (PIN)).

Summary

There is an increasing trend for encrypting user plane traffic going through an operator^'s network. Most applications run over HTTPS today. In the mid/long term, Quick UDP Internet Connections (QUIC) is a likely candidate to become the main transport protocol in the user plane and the inventors have appreciated that current methods for IP traffic management will not be usable with QUIC, as they are also not usable for HTTPS. A challenge for operators is to continue providing the same traffic management functionality when the user^'s IP traffic is encrypted, specifically content filtering and redirection are not possible today with the existing mechanisms.

It is an aim of the invention to provide management of IP traffic, e.g. by redirection and/or content filtering, when the IP traffic is encrypted. The inventors have realized that information about a requested URL cannot be extracted from encrypted traffic using DPI because of the encryption. The URL is not readable. Further, the structure of encrypted IP traffic using protocols such as QUIC is different than as using HTTPS and so the methods used in the prior art are not usable on encrypted IP traffic. In accordance with an aspect of the invention, there is provided a network node for use as a Policy Control Enforcement Function, PCEF, or a Traffic Detection Function, TDF, for managing Internet Protocol, IP, traffic in a telecommunications network. The network node comprises a receiving means, which may be a receiver, configured to receive a session establishment message from a User Equipment, UE, the session establishment message for establishing a session between the UE and a web server hosting a URL which the UE requests. The network node also comprises an extractor means, which may be an extractor configured to extract from the session establishment message data indicative of the requested URL. The network node also comprises a query managing means, which may be a query manager configured to generate a query based on the extracted data and to control a transmitting means, which may be a transmitter, to transmit the generated query to a further network node configured to provide policy data specifying how IP traffic between the UE and the web server should be managed. The receiver is further configured to receive, from the further network node, policy data relating to the requested URL and for use in management of subsequent IP traffic between the UE and the web server hosting the requested URL.

Optionally, the session establishment message comprises one of: a domain name server, DNS, query; a Transport Layer Security, TLS, Client Hello message; and a Secure Sockets Layer, SSL, Server Certificate message. Optionally, the extracted data indicative of the requested URL comprises one of: a fully qualified domain name, FQDN; a Server Name Indication, SNI; and a Subject Common Name, SCN.

Optionally, the query manager is configured to generate the query comprising one of: the extracted data indicative of the requested URL; and a substitute URL based on the extracted data indicative of the requested URL. Optionally, the session establishment message is a DNS query and the extracted data indicative of the requested URL is a fully qualified domain name, FQDN, wherein the query manager is further configured to control the transmitter to transmit the DNS query to a DNS server, and wherein the receiver is configured to receive from the DNS server a DNS answer identifying a web server hosting the requested URL.

Optionally, the network node further comprises a policy managing means, which may be a policy manager, configured to store in memory the identified web server, the received policy data and the extracted FQDN, and further configured to detect subsequent IP traffic between the UE and the identified web server and to manage that subsequent IP traffic according to the stored policy data.

Optionally, the policy manager is configured to detect a transport protocol initialization message between the UE and the identified web server, and further configured to modify the transport protocol initialization message according to the received policy data. In an embodiment, the transport protocol may be a Transmission Control Protocol, TCP, and the transport protocol initialization message may be a TCP Synchronisation, TCP SYN, message.

Optionally, the extractor is further configured to extract a Time to Live, TTL, from the received DNS query, and wherein the policy manager is configured to store the identified web server, the received policy data and the extracted FQDN with an associated TTL (or policy data) that is based on the TTL extracted from the received DNS query. The associated TTL may be determined by the policy manager. The associated TTL may be substantially the same as the TTL extracted from the DNS query. Optionally, the query manager is configured to generate a further DNS answer comprising the identified web server, the received policy data and the extracted FQDN, and wherein the query manager is further configured to control the transmitter to transmit the generated further DNS answer to the UE, such that the UE is able to manage subsequent IP traffic between the UE and the identified web server according to the received policy data.

Optionally, the received policy data indicates that subsequent IP traffic should be redirected, allowed or blocked.

According to the invention in an aspect, there is provided a method for operating a network node for use as a Policy Control Enforcement Function, PCEF, or a Traffic Detection Function, TDF, for managing Internet Protocol, IP, traffic in a telecommunications network. The method comprises receiving, by a receiver, a session establishment message from a User Equipment, UE, the session establishment message for establishing a session between the UE and a web server hosting a URL which the UE requests. The method comprises extracting, by an extractor, from the session establishment message data indicative of the requested URL. The method comprises generating, by a query manager, a query based on the extracted data and controlling a transmitter, by the query manager, to transmit the generated query to a further network node configured to provide policy data specifying how IP traffic between the UE and the web server should be managed. The method comprises receiving, by the receiver, from the further network node, policy data relating to the requested URL and for use in management of subsequent IP traffic between the UE and the web server hosting the requested URL.

Optionally, the session establishment message comprises one of: a domain name server, DNS, query; a Transport Layer Security, TLS, Client Hello message; and a Secure Sockets Layer, SSL, Server Certificate message.

Optionally, the extracted data indicative of the requested URL comprises one of: a fully qualified domain name, FQDN; a Server Name Indication, SNI; and a Subject Common Name, SCN. Optionally, the method further comprises the query manager generating the query comprising one of: the extracted data indicative of the requested URL; and a substitute URL based on the extracted data indicative of the requested URL. Optionally, the session establishment message is a DNS query and the extracted data indicative of the requested URL is a fully qualified domain name, FQDN, the method further comprising the query manager controlling the transmitter to transmit the DNS query to a DNS server, and the receiver receiving from the DNS server a DNS answer identifying a web server hosting the requested URL.

Optionally, the method further comprises: storing in memory, by a policy manager, the identified web server, the received policy data and the extracted FQDN, and detecting, by the policy manager, subsequent IP traffic between the UE and the identified web server and managing that subsequent IP traffic according to the stored policy data.

Optionally, the method further comprises the policy manager detecting a transport protocol initialization message between the UE and the identified web server, and modifying the transport protocol initialization message according to the received policy data. In an embodiment, the transport protocol may be a Transmission Control Protocol, TCP, and the transport protocol initialization message may be a TCP Synchronisation, TCP SYN, message.

Optionally, the method further comprises the extractor extracting a Time to Live, TTL, from the received DNS query, and the policy manager (218) storing the identified web server, the received policy data and the extracted FQDN with an associated TTL (or policy data) based on the TTL extracted from the received DNS query. The associated TTL may be determined by the policy manager. The associated TTL may be substantially the same as the TTL extracted from the DNS query. Optionally, the method further comprises the query manager generating a further DNS answer comprising the identified web server, the received policy data and the extracted FQDN, and the query manager controlling the transmitter to transmit the generated further DNS answer to the UE, such that the UE is able to manage subsequent IP traffic between the UE and the identified web server according to the received policy data. Optionally, the received policy data indicates that subsequent IP traffic should be redirected, allowed or blocked. According to the invention in an aspect, there is provided a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out any method described herein.

According to the invention in an aspect, there is provided a carrier containing the computer program above, wherein the carrier is one of an electronic signal, optical signal, radio signal, or non-transitory computer readable storage medium.

Brief description of drawings Figure 1 is a block schematic diagram of a PCC architecture;

Figure 2 is a block schematic diagram of a PCEF or TDF;

Figure 3 is a signalling diagram showing a method for management of traffic in a telecommunications system;

Figure 4 is a signalling diagram showing a method for management of traffic in a telecommunications system; and

Figure 5 is a signalling diagram showing a method for management of traffic in a telecommunications system;

Detailed description

Generally, disclosed herein are methods and apparatus for management of encrypted IP traffic in a telecommunications network. The methods and apparatus disclosed recognise that known DPI techniques will not be usable to extract relevant information, such as a target URL, from encrypted IP data packets. The methods and apparatus disclosed therefore provide novel ways to categorise IP traffic for subsequent traffic management, such as redirection and/or content filtering.

In specific exemplary methods and apparatus, data indicative of a requested URL, such as a Fully Qualified Domain Name (FQDN), may be extracted from a session establishment message, such as a Domain Name Server (DNS) query or Client Hello message, sent from a User Equipment (UE) to the PCEF 102 or the TDF 104. The session establishment message is not encrypted. The extracted data may be used to create a substitute URL that may be used to provide content classification in the normal way.

Proposed herein there are solutions to support content filtering and redirection for encrypted traffic based on DPI techniques, although the solutions are valid both for HTTPS and QUIC. Exemplary solutions proposed herein may be implemented in the Evolved Packet Gateway (EPG), or in the Packet Data Network Gateway (PGW), as enhancements of the existing content filtering and redirection features.

Figure 2 shows a schematic representation of a network node 200 for implementing a PCEF 102 or a TDF 104. The network node 200 may be a PCEF 102 or TDF 104 of Figure 1 . The network node 200 comprises a transmitter 202 and a receiver 204. The transmitter 202 and receiver 204 may be in data communication with other network entities in a telecommunications network and are configured to transmit and receive data accordingly.

The network node 200 further comprises a memory 206 and a processor 208. The memory 206 may comprise a non-volatile memory and/or a volatile memory. The memory 206 may have a computer program 210 stored therein. The computer program 210 may be configured to undertake the methods disclosed herein. The computer program 210 may be loaded in the memory 206 from a non-transitory computer readable medium 212, on which the computer program is stored. The processor 208 is configured to undertake one or more of the functions of an extractor 214, a query manager 216 and a policy manager 218, as set out below.

Each of the transmitter 202 and receiver 204, memory 206, processor 208, extractor 214, query manager 216 and policy manager 218 is in data communication with the other features 202, 204, 206, 208, 210, 214, 216, 218 of the network node 200. The network node 200 can be implemented as a combination of computer hardware and software. In particular, the extractor 214, query manager 216 and policy manager 218 may be implemented as software configured to run on the processor 208, or as combinations of hardware and software in separate modules. The memory 206 stores the various programs/executable files that are implemented by a processor 208, and also provides a storage unit for any required data. The programs/executable files stored in the memory 206, and implemented by the processor 208, can include the extractor 214, query manager 216 and policy manager 218, but are not limited to such.

Exemplary methods and apparatus support content filtering and redirection functionality when the traffic is encrypted and may apply both to HTTPS traffic, using anyone of Transport Layer Security (TLS) and Secure Sockets Layer (SSL), and QUIC traffic. Different scenarios are envisaged.

In a first scenario, a UE triggers a DNS query. In such circumstances the PCEF 102 and/or the TDF 104 may modify the destination IP address of IP traffic to provide content filtering and/or redirection of the traffic. This is shown in Figure 3. Alternatively or in addition, the PCEF 102 and/or the TDF 104 may modify the DNS answer transmitted to the UE in response to the DNS query. This is shown in Figure 4.

In a second scenario, the UE does not trigger a DNS query because it has already done so and has a DNS answer cached from a previous request. In such scenarios, the PCEF 102 and/or the TDF 104 may send a representation of a URL, constructed with a TLS Server Name Indication (SNI) extracted from the traffic, to an ICAP server and receive a content classification in response. This is shown in Figure 5.

An exemplary signaling flow is now described with reference to Figure 3, which shows signaling for an exemplary method of a PCEF 102 based solution, a similar solution can also be implemented using the TDF 104 instead of the PCEF 102. At UE IP-CAN session establishment (Packet Data Protocol (PDP) context creation in the case of Third Generation (3G) networks), the PCEF 102 (which may e.g. be a Gateway General Packet Radio Service (GPRS) Support Node (GGSN)) will convey to the PCRF 100 a subscriber identity (e.g. an International Mobile Subscriber Identity (IMSI) and/or a Mobile Subscriber Integrated Services Digital Network (ISDN) Number (MSISDN)) in a Gx initial Credit Control Request (CCR) message.

Based on the received subscriber identity (IMSI and/or MSISDN), the PCRF 100 retrieves subscriber profile information relating to the subscriber (UE, or user) from the SPR 1 10. The subscriber profile includes a parameter indicating whether, for this particular user, IP traffic should be managed using, for example, content filtering and/or redirection. For example, the user may be subject to parental control.

The PCRF 100 activates content filtering functionality for this subscriber (e.g. by means of activating a Charging-Rule-Base-Name).

The IP-CAN session establishment is completed (create a PDP context response in the case of 3G networks).

The UE starts the browser and selects a certain URL to which access is requested. The UE triggers a DNS query to the target URL/FQDN.

The receiver 204 of the PCEF 102 receives the DNS query and the extractor 214 extracts (e.g. using DPI techniques) and stores in memory 206 the target FQDN.

The query manager 216 of the PCEF 102 generates an ICAP query based on the extracted FQDN. The ICAP query might contain the FQDN in a new field. Alternatively or in addition, the ICAP query might comprise a substitute URL generated using the extracted FQDN. That is, the ICAP query may contain a representation of a URL constructed with the FQDN extracted from the traffic, e.g. by adding "http://" to the beginning of the FQDN. The query manager 216 controls the transmitter 202 to transmit the ICAP query based on the extracted FQDN towards an external ICAP server. It is noted that sending an ICAP query with a new field for the FQDN will require of changes to the ICAP server, while generating a substitute URL avoids those changes while at the same time maintaining the same level of resolution (both the FQDN and the substitute URL based on the FQDN contain the same information, that is the domain).

The ICAP server receives the ICAP query and checks the FQDN or substitute URL against its internal database and responds to the PCEF 102 with policy data, which may comprise or identify a policy (e.g. allow, block or redirect) corresponding to the requested URL for that user. In the exemplary case of Figure 3, the policy is to redirect, but allow and block are also possible policies. This allows for a plurality of available enforcements to be applied to encrypted traffic. Optionally, the ICAP server can also transmit a redirect server IP address to the PCEF 102. In that case, the redirect server IP address is assumed to be locally configured at PCEF 102. For example, these policies may be:

^■ Allow. If the enforcement dictated by the ICAP server is "allow", the policy manager 218 ensures traffic flow continues unhindered, meaning that the "allow" Content Filtering enforcement has been applied to this encrypted flow.

^■ Block. If the enforcement required is "drop", the policy manager 218 ensures any current and subsequent packets for this flow will be dropped, implementing the "drop" Content Filtering enforcement for encrypted traffic.

^■ Redirect (shown in Figure 3). Optionally, the ICAP server can also transmit a Redirect Server IP address to the PCEF 102. In this case, it is assumed to be locally configured at PCEF 102 and the policy manager 218 is configured to redirect subsequent IP traffic according to the policy data. Applying a "redirect" requires the policy data to be applied starting with the first packet of the flow, not after the 3-way handshake or security negotiation. 322 The query manager 216 of the PCEF 102 transmits the DNS query towards the DNS server. This may happen in parallel with 318-320 above.

324 The DNS server transmits an answer to the PCEF 102 comprising data identifying a Web Server IP address corresponding to the target FQDN. The identified Web Server hosts the requested URL. 326 The PCEF 102 receives the DNS answer and extracts (e.g. through DPI techniques) the target IP address (Web Server IP address). The policy manager 218 stores the Web Server IP address and links it to the extracted FQDN and to the policy data (redirect action in this case). The policy manager 218 of the PCEF 102 may also run a local cache for the retrieved Web Server IP address, with a Time to Live (TTL) to be the same as a TTL field in the DNS answer received from the DNS server. Therefore, an FQDN/IP association will be cached by the PCEF 102 and may be used for subsequent traffic to/from the same or other UEs to the same FQDN. As explained below, this may provide IP traffic management for encrypted traffic in case that a UE does not trigger a

DNS procedure, as they may have locally cached the FQDN/IP mapping. Therefore, the enforcements dictated by the ICAP server in the policy data can be later applied to all subsequent traffic to the Web Server IP address originally resolved. If the policy data indicates 'block', the PCEF drops corresponding IP traffic, if the policy data indicates

'pass', the PCEF lets corresponding IP traffic go freely, but when the policy data indicates 'redirection' the following exemplary steps may apply. 328 The PCEF 102 forwards the DNS answer to the UE.

If the policy data indicates 'block', the PCEF drops corresponding IP traffic, if the policy data indicates 'pass', the PCEF lets corresponding IP traffic go freely, but when the policy data indicates 'redirection' the following exemplary steps may apply. The UE triggers a Transport Control Protocol (TCP) connection towards the Web Server identified in the DNS answer from the DNS server. This may be done by sending a TCP Synchronise (SYN) with a destination IP address set to Web_Server_IP_address (i.e. the Web Server IP address identified in the DNS answer from the DNS server). In case of using UDP or other transport protocol instead of TCP, the TCP SYN message discussed in the following should be replaced by an appropriate UDP message or other transport protocol message.

The policy manager 218 of the PCEF 102 detects (e.g. through DPI) the TCP SYN message and checks the destination IP address in the TCP SYN message against the stored Web Server IP address that is linked to the extracted FQDN and to the policy data (redirect action in this case). If the destination IP address matches the stored Web Server IP address, the policy manager 218 applies the enforcement dictated by ICAP server, which can be allow, block or redirect. In this case, there is a match and the policy dictates that the IP traffic should be redirected.

The PCEF 102 forwards the TCP SYN to the redirect server.

The redirect server triggers a TCP SYN ACK message to the PCEF 102.

The policy manager 218 of the PCEF 102 detects (through DPI) the TCP SYN ACK message from the redirect server and replaces the source IP address with the stored Web Server IP address that is linked to the extracted FQDN and to the policy data.

The PCEF 102 forwards the TCP SYN ACK to the UE.

For all the subsequent IP traffic in this TCP flow, the policy manager 218 does the following:

^■ For Uplink (UL) traffic, it replaces the destination IP address by the redirect server IP address. ^■ For Downlink (DL) traffic, it replaces the source IP address by the stored Web Server IP address that is linked to the extracted FQDN and to the policy data. Figure 4 shows a signaling diagram of a method for managing IP traffic. Figure 4 shows a PCEF based approach, but a similar solution can also be obtained replacing the PCEF with a TDF, as will be understood by the skilled person.

400-420 These steps are the same as steps 300-320 in Figure 3.

422 The receiver 204 of the PCEF 102 receives an ICAP answer message, which comprises policy data, from the ICAP server. The policy data in this case indicates that redirect action is required for IP traffic. The query manager 216 of the PCEF 102 drops the DNS query received in 414 above. That is, the PCEF 102 does not forward the DNS query to the

DNS server. Instead, the query manager 216 (using DPI capabilities) generates a DNS answer message. The generated DNS answer comprises: · The IP address of the redirect server

(Redirect_Server_IP_address); and

• A short TTL. This short TTL is preferably in the range of few (e.g. 1 -2, 1 -5, 1 -10 or 1 -30) seconds in contrast with the TTL returned by the DNS server, which is often in the range of minutes or hours. This is to avoid the UE storing in its internal cache for a long time the mapping between the requested Web Server URL/Domain and the IP address of the redirect server. This can also be used for use cases like One Time Redirection (or short time redirection).

Optionally, the response received from the ICAP server at 420 may comprise the redirect server IP address. The redirect server IP address may be provided by the ICAP server or may be locally configured at the PCEF/TDF. In this case, it is assumed to be locally configured at the PCEF 102. 424 The policy manager 218 controls the transmitter to transmit the generated DNS answer message (in 422 above) towards the UE. 426 The UE triggers a TCP SYN to the redirect server IP address (based on the DNS answer received in 424 above).

428-430 The 3-way handshake is completed (TCP SYN ACK and TCP ACK) between UE and the redirect server. A corresponding procedure can be applied if UDP or other transport protocol is used instead of TCP.

After the TCP handshake is completed, the UE will trigger TLS handshake. Subsequent HTTPS traffic in this flow will be directed to the redirect server, as in Figure 3.

Figure 5 shows a signaling diagram of a method for managing IP traffic. In the exemplary method shown in Figure 5, the UE does not send a DNS query. The UE has cached a mapping between a requested URL and a Web Server IP address to host the requested URL. This may have been undertaken using at least part of the methods described above. Therefore, the UE does not trigger a DNS query, but instead directly triggers a TCP connection (TCP SYN) towards the Web Server IP address hosting the requested URL. As commented above, in case of using UDP or other transport protocol instead of TCP, the TCP SYN message discussed with reference to Figure 5 should be replaced by an appropriate UDP message or other transport protocol message. This may be done by transmitting a TCP SYN with a destination IP address set to the Web Server IP address (Web_Server_IP_address - e.g. an IP address received in some past DNS interaction and cached in the UE) hosting the requested URL. There are two possible circumstances: • The PCEF 102 has cached the Web Server IP address hosting the requested URL from a previous transaction flow for that particular UE. In exemplary arrangements this may be achieved using methods described above, in particular in step 326 of Figure 3). In this case, the policy manager 218 of the PCEF 102 modifies the TCP SYN message by replacing the Web Server IP address by the redirect server IP address linked thereto; and

• The PCEF 102 has not cached the Web Server IP address from a previous transaction flow for that particular UE. This case is shown in Figure 5 and detailed below.

Figure 5 shows a PCEF based solution, a similar solution can also be obtained replacing the PCEF with a TDF, as will be understood by the skilled person. 500-512 These steps are the same as steps 300-312 and steps 400-412 in Figures 3 and 4.

514 The UE starts a browser and requests a certain URL. As we are in the second scenario, the UE has cached a mapping between the target URL and Web server IP address to host it. In this case, the UE does not trigger any DNS query, but instead it directly triggers a TCP connection (TCP SYN) towards the Web Server IP address, by sending a TCP SYN with a destination IP address set to Web_Server_IP_address (i.e. an IP address received in some past DNS interaction and cached in the UE). There are two alternatives here, and already discussed above:

^■ The PCEF 102 has cached the Web Server IP address from a previous transaction for that particular UE (shown in Step 326 of Figure 3). In this case, the PCEF 102 intercepts the TCP SYN and can modify the TCP SYN message by replacing the Web Server IP address by the Redirect Server IP address. This modified TCP SYN message is sent outside through the same interface (at PCEF) and the IP routers outside PCEF will route it to the redirect server accordingly (as the TCP SYN has the destination IP address of the redirect server). This alternative is not illustrated in any drawing.

^■ The PCEF 102 has not previously cached the Web Server IP address from a previous transaction for the particular UE. This is the case depicted in Figure 5 and detailed below.

The Web Server responds to the UE with the corresponding TCP SYN ACK.

The UE completes the 3-way handshake by sending the corresponding TCP ACK.

The UE starts sending application data, i.e. IP traffic. There are two

^■ The UE uses cleartext HTTP as the application protocol, in which case traditional mechanisms for management of IP traffic (e.g. content filtering or redirection) can be performed. For example, this may be done by inspection of IP traffic to determine the requested URL via DPI in the PCEF 102 or the TDF 104 and reporting to ICAP server for categorization; or ^■ The UE uses an encryption transport protocol like Secure Sockets Layer (SSL) or Transport Layer Security (TLS) or QUIC. This is the case shown in Figure 5, which uses the example of TLS and a TLS Client Hello message, although the same process may be used for SSL and a Server

Certificate message. The receiver 204 of the PCEF 102 receives a TLS Client Hello message containing a Server Name Indication field (SNI). The Client Hello message may be received after the TCP ACK, which finishes the 3-way

TCP handshake. Alternatively, the receiver 204 may receive a Server Certificate message containing a Subject Common Name (SCN) field at the end of the SSL or TLS negotiation. The extractor 214 of the PCEF 102 inspects and extracts the SNI or SCN value. Both the SNI and the SCN take similar form as an FQDN. The query manager 216 of the PCEF 102 generates an ICAP query with the extracted SNI or SCN value from 522. The query may contain - similar to the example using a DNS query - a new specific field containing the SNI or the SCN. Alternatively, the query manager 216 may generate a substitute URL using the extracted SNI or SCN to be included in the ICAP query. The substitute URL may be generated by adding "http://" to the beginning of the SNI or SCN. In exemplary arrangements, one of the SNI or the SCN should be used to generate the ICAP query. When both the SNI and the SCN are available, one may be chosen. In some exemplary arrangements, the SNI may be preferred as it appears before the SCN in the sequence of packets of a TCP flow. As previously, sending a new field with either the SNI or the SCN will require of changes to the ICAP server while generating the substitute URL avoids those changes while at the same time maintaining the same level of resolution (both the SNI, the SCN and the substitute URL based on either the SNI or the SCN contain the same information, that is the domain). The query manager 216 controls the transmitter 202 to transmit the generated query to the ICAP server. The ICAP server checks the SNI, SCN or generated URL against its internal database and responds to the PCEF 102 with the corresponding policy data (e.g. allow, block or redirect):

^■ Redirect (shown in Figure 5). Optionally, the ICAP server can also transmit a Redirect Server IP address to the PCEF 102. In this case, it is assumed to be locally configured at PCEF 102 and the policy manager 218 is configured to redirect subsequent IP traffic according to the policy data. Applying a "redirect" requires the policy data to be applied starting with the first packet of the flow, not after the 3-way handshake or security negotiation.

Using the example of a "redirect" enforcement, and using either the Redirect Server IP address retrieved from the ICAP server or a locally configured value, the policy manager 218 of the PCEF 102 controls the transmitter 202 to transmit the UL traffic to the Redirect Server. This may be done to TCP flows on the first packet of the flow, i.e. TCP SYN. This will be the case for flows using the same destination IP address as some other flow filtered previously. Since the policy manager stores a local resolution table mapping Web Server IP addresses of the Web Servers hosting requested URLs to received policies (e.g. allow, block or redirect), it is possible that a flow filtered on a later packet will populate the table with a Web Server IP address and policy pair. Redirection cannot be applied to this particular flow but could be applied to subsequent flows to the same destination. For all the traffic in this TCP flow, the policy manager 218 does the following:

^■ For UL traffic, replaces the destination IP address with the Redirect Server IP address.

^■ For DL traffic, replaces the source IP address with the Web Server IP address.

The exemplary methods and apparatus disclosed herein apply both to the case of encrypted traffic (e.g. HTTPS as HTTP traffic encrypted over SSL or TLS) and non- encrypted traffic (e.g. HTTP browsing in cleartext, i.e. with no SSL or TLS). The exemplary methods and apparatus disclosed herein also apply to traffic encrypted with QUIC. The exemplary methods and apparatus disclosed herein also apply to UDP or any other transport protocol. In Figure 5, the PCEF 102 with DPI capabilities or the TDF 104 may be configured to extract the TLS 1 .3 SNI from the QUIC Client Hello message. The exemplary methods and apparatus disclosed herein also apply to the general redirection use case (i.e. when there is no content filtering).

Finally, it is noted again that the exemplary methods and apparatus disclosed herein apply to the following scenarios:

• PCEF with DPI capabilities (the one detailed in this IvD and shown in Figures 3, 4 and 5);

• TDF (similar to the case above, the main difference being using Sd interface instead of Gx).

A computer program may be configured to provide any of the above described methods. The computer program may be provided on a computer readable medium. The computer program may be a computer program product. The product may comprise a non-transitory computer usable storage medium. The computer program product may have computer-readable program code embodied in the medium configured to perform the method. The computer program product may be configured to cause at least one processor to perform some or all of the method. Various methods and apparatus are described herein with reference to block diagrams or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).

Computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer- readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks.

A tangible, non-transitory computer-readable medium may include an electronic, magnetic, optical, electromagnetic, or semiconductor data storage system, apparatus, or device. More specific examples of the computer-readable medium would include the following: a portable computer diskette, a random access memory (RAM) circuit, a read-only memory (ROM) circuit, an erasable programmable read-only memory (EPROM or Flash memory) circuit, a portable compact disc read-only memory (CD- ROM), and a portable digital video disc read-only memory (DVD/Blu-ray).

The computer program instructions may also be loaded onto a computer and/or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and/or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks.

Accordingly, the invention may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated.

The skilled person will be able to envisage other embodiments without departing from the scope of the appended claims.

Claims

CLAIMS:

1. A network node (200) for use as a Policy Control Enforcement Function, PCEF, (102) or a Traffic Detection Function, TDF, (104) for managing Internet Protocol, IP, traffic in a telecommunications network, the network node comprising: a receiver (204) configured to receive a session establishment message from a User Equipment, UE, the session establishment message for establishing a session between the UE and a web server hosting a URL which the UE requests;

an extractor (214) configured to extract from the session establishment message data indicative of the requested URL; and

a query manager (216) configured to generate a query based on the extracted data and to control a transmitter (202) to transmit the generated query to a further network node configured to provide policy data specifying how IP traffic between the UE and the web server should be managed,

wherein the receiver is further configured to receive, from the further network node, policy data relating to the requested URL and for use in management of subsequent IP traffic between the UE and the web server hosting the requested URL.

2. A network node (200) according to claim 1 , wherein the session establishment message comprises one of: a domain name server, DNS, query; a Transport Layer

Security, TLS, Client Hello message; and a Secure Sockets Layer, SSL, Server Certificate message.

3. A network node (200) according to claim 1 or 2, wherein the extracted data indicative of the requested URL comprises one of: a fully qualified domain name,

FQDN; a Server Name Indication, SNI ; and a Subject Common Name, SCN.

4. A network node (200) according to any preceding claim, wherein the query manager (216) is configured to generate the query comprising one of: the extracted data indicative of the requested URL; and a substitute URL based on the extracted data indicative of the requested URL.

5. A network node (200) according to any preceding claim, wherein the session establishment message is a DNS query and the extracted data indicative of the requested URL is a fully qualified domain name, FQDN, wherein the query manager (216) is further configured to control the transmitter (202) to transmit the DNS query to a DNS server, and wherein the receiver (204) is configured to receive from the DNS server a DNS answer identifying a web server hosting the requested URL.

6. A network node (200) according to claim 5, further comprising:

a policy manager (218) configured to store in memory (206) the identified web server, the received policy data and the extracted FQDN, and further configured to detect subsequent IP traffic between the UE and the identified web server and to manage that subsequent IP traffic according to the stored policy data.

7. A network node (200) according to claim 6, wherein the policy manager (218) is configured to detect a transport protocol initialization message between the UE and the identified web server, and further configured to modify the transport protocol initialization message according to the received policy data.

8. A network node (200) according to claim 7, wherein the transport protocol is a Transmission Control Protocol, TCP, and the transport protocol initialization message is a TCP Synchronisation, TCP SYN, message.

9. A network node (200) according to any of claims 6 to 8wherein the extractor (214) is further configured to extract a Time to Live, TTL, from the received DNS query, and wherein the policy manager (218) is configured to store the identified web server, the received policy data and the extracted FQDN with an associated TTL that is based on the TTL extracted from the received DNS query.

10. A network node (200) according to any of claims 5 to 9, wherein the query manager (216) is configured to generate a further DNS answer comprising the identified web server, the received policy data and the extracted FQDN,

and wherein the query manager is further configured to control the transmitter (202) to transmit the generated further DNS answer to the UE, such that the UE is able to manage subsequent IP traffic between the UE and the identified web server according to the received policy data.

11 . A network node (200) according to any preceding claim, wherein the received policy data indicates that subsequent IP traffic should be redirected, allowed or blocked.

12. A method for operating a network node (200) for use as a Policy Control Enforcement Function, PCEF, (102) or a Traffic Detection Function, TDF, (104) for managing Internet Protocol, IP, traffic in a telecommunications network, the method comprising:

receiving (314; 414; 520), by a receiver (204), a session establishment message from a User Equipment, UE, the session establishment message for establishing a session between the UE and a web server hosting a URL which the UE requests;

extracting (316; 416; 522), by an extractor (214), from the session establishment message data indicative of the requested URL;

generating (318; 418; 524), by a query manager (216), a query based on the extracted data and controlling a transmitter (202), by the query manager (216), to transmit the generated query to a further network node configured to provide policy data specifying how IP traffic between the UE and the web server should be managed; and

receiving (320; 420; 526), by the receiver, from the further network node, policy data relating to the requested URL and for use in management of subsequent IP traffic between the UE and the web server hosting the requested URL.

13. A method according to claim 12, wherein the session establishment message comprises one of: a domain name server, DNS, query; a Transport Layer Security,

TLS, Client Hello message; and a Secure Sockets Layer, SSL, Server Certificate message.

14. A method according to claim 12 or 13, wherein the extracted data indicative of the requested URL comprises one of: a fully qualified domain name, FQDN; a Server

Name Indication, SNI; and a Subject Common Name, SCN.

15. A method according to any of claims 12 to 14, further comprising the query manager (216) generating (318; 418; 524) the query comprising one of: the extracted data indicative of the requested URL; and a substitute URL based on the extracted data indicative of the requested URL.

16. A method according to any of claims 12 to 15, wherein the session establishment message is a DNS query and the extracted data indicative of the requested URL is a fully qualified domain name, FQDN, the method further comprising the query manager (216) controlling the transmitter (202) to transmit (322) the DNS query to a DNS server, and the receiver (204) receiving (324) from the DNS server a DNS answer identifying a web server hosting the requested URL.

17. A method according to claim 16, further comprising:

storing (326) in memory (206), by a policy manager (218), the identified web server, the received policy data and the extracted FQDN, and

detecting (342), by the policy manager, subsequent IP traffic between the UE and the identified web server and managing that subsequent IP traffic according to the stored policy data.

18. A method according to claim 17, further comprising the policy manager (218) detecting (332) a transport protocol initialization message between the UE and the identified web server, and modifying the transport protocol initialization message according to the received policy data.

19. A method according to claim 18, wherein the transport protocol is a Transmission Control Protocol, TCP, and the transport protocol initialization message is a TCP Synchronisation, TCP SYN, message.

20. A method according to any of claims 17 to 19, further comprising the extractor (214) extracting a Time to Live, TTL, from the received DNS query, and the policy manager (218) storing the identified web server, the received policy data and the extracted FQDN with an associated TTL based on the TTL extracted from the received DNS query.

21 . A method according to any of claims 16 to 20, further comprising the query manager (216) generating (422) a further DNS answer comprising the identified web server, the received policy data and the extracted FQDN, and comprising the query manager controlling the transmitter (202) to transmit (424) the generated further DNS answer to the UE, such that the UE is able to manage subsequent IP traffic between the UE and the identified web server according to the received policy data.

22. A method according to any of claims 12 to 21 , wherein the received policy data indicates that subsequent IP traffic should be redirected, allowed or blocked.

23. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of claims 12 to 22.

24. A carrier containing the computer program of claim 23, wherein the carrier is one of an electronic signal, optical signal, radio signal, or non-transitory computer readable storage medium.