EP-3769489-B1 - TRAFFIC FORWARDING AND DISAMBIGUATION BY USING LOCAL PROXIES AND ADDRESSES

EP3769489B1EP 3769489 B1EP3769489 B1EP 3769489B1EP-3769489-B1

Inventors

AYYADEVARA, Seetharama Sarma
GUTPA, Sumeet
GERO, CHARLES E.
BENNY, Stephan
TATTI, Pravin
KUMAR, MANOJ
CHOUDHARY, SEEMANT
QUIROS, Robert Lauro
ADIGOPULA, Priyatham Phani Srinath
VENKATESHA, Poornima

Dates

Publication Date: 20260506
Application Date: 20190322

Claims (11)

An apparatus (600) operating in association with a computing machine, the computing machine being distinct from the apparatus and executing an enterprise application (610), the enterprise application having a configuration comprising a domain name the enterprise application runs on and on what port the enterprise application listens, the apparatus comprising: a processor (202); a computer memory (602) storing an operating system kernel (204), and computer program instructions which, when executed by the processor, cause the processor to forward traffic destined for the enterprise application, the computer program instructions comprising: program code which, when executed by the processor, causes instantiation of a Domain Name System server (604) hosted by the apparatus (600); and program code which, when executed by the processor, causes instantiation of a local proxy (606) hosted by the apparatus (600); wherein, in response to receiving the configuration from the enterprise application, the apparatus (600) is caused, by the computer program instructions, to: pick a unique localhost address, assign the unique localhost address in a mapping created by the Domain Name System server (604) to the domain name in the received configuration, and begin listening on an address/port pair comprising the assigned unique localhost address and the port identified in the received configuration, so that the Domain Name System server (604) is configured to on-ramp traffic destined for the enterprise application to the local proxy; wherein in response to receipt of a query including a hostname from an application or process (608) running in the apparatus, and when the hostname in the query matches a domain name in the mapping created by the Domain Name System server, the Domain Name System server is configured to return to the application or process the matching unique localhost address, the application or process being then configured to attempt to connect or send packets to the returned localhost address; wherein in response to connection of the application or process to the matching unique localhost address on the port, the application or process is configured to connect to the local proxy (606); and wherein the local proxy (606) is configured to establish a connection to an external proxy (616) located between the apparatus and the computing machine on which the enterprise application executes and to steer traffic directed to the matching unique localhost address and that is destined for the enterprise application to the external proxy (616), said external proxy (616) being determined based on a policy on the local proxy (606).
The apparatus as described in claim 1, wherein the unique localhost address is an unused address in Classless Inter-Domain Routing block 127.0.0.0/8.
The apparatus as described in claim 1, wherein the local proxy is further configured to annotate data prior to sending the data as annotated to the external proxy.
The apparatus as described in claim 3, further including the local proxy tunneling the data as annotated from the local proxy to the external proxy.
The apparatus as described in claim 4, wherein the external proxy is an edge server in a content delivery network.
The apparatus as described in claim 1, wherein the local proxy is configured to provide an additional service that is one of: applying a Quality of Service; restricting traffic that is determined to exceed a mobile quota; enabling a connection termination; enabling a step-up authentication; and applying a security policy.
The apparatus as described in claim 1, wherein the Domain Name System server remaps to the unique localhost address a set of IP addresses based on listening sockets.
The apparatus as described in claim 1, wherein the unique localhost address is an address in a defined Classless Inter-Domain Routing address range that is user-configured.
The apparatus as described in claim 1, wherein the unique localhost address is an address in a defined Classless Inter-Domain Routing address range that is auto-discovered.
The apparatus as described in claim 1, wherein the unique localhost address is an address in a defined Classless Inter-Domain Routing address range that is other than a range being serviced by a Virtual Private Network.
The apparatus as described in claim 1, wherein the computer program instructions are further configured to intercept and process a Domain Name System SRV request while mapping the hostname.

Description

BACKGROUND Technical Field This application relates generally to techniques for managing traffic on a network. Brief Description of the Related Art Distributed computer systems are well-known in the prior art. One such distributed computer system is a "content delivery network" (CDN) or "overlay network" that is operated and managed by a service provider. The service provider typically provides the content delivery service on behalf of third parties (customers) who use the service provider's shared infrastructure. A distributed system of this type typically refers to a collection of autonomous computers linked by a network or networks, together with the software, systems, protocols and techniques designed to facilitate various services, such as content delivery, web application acceleration, or other support of outsourced origin site infrastructure. A CDN service provider typically provides service delivery through digital properties (such as a website), which are provisioned in a customer portal and then deployed to the network. There exist use cases in security, performance, access, and beyond where it is beneficial to redirect traffic originating on an endpoint that is in-route to a destination to instead egress through an interim proxy. Among other things, the interim proxy can be used for security services, performance upgrades, visibility and logging, acceptable use policies, data treatments, encapsulation, delivery to other proxies, and more. When traffic arrives on such a proxy, and after any necessary treatments are performed, the proxy must be able to determine the next hop or destination to which to forward the traffic. There are two general broad categories for how this can be achieved, and their applicability is determined by whether the traffic in question is proxy-friendly. As used herein, the notion of being proxy-friendly is defined as the ability to determine where the traffic is originally destined at Open System Interconnection (OSI) Layers 5 through 7 in the data flow, without any external annotation. An example of this is the HOST header in HTTP (HyperText Transfer Protocol) or the SNI extension in TLS (Transport Layer Security Protocol). Both allow a proxy that has been arbitrarily inserted into a data flow and without access to the original destination address to discover the intended final destination. Traffic that is not proxy-friendly needs some other way to disambiguate or discover the final destination. One method that is well known in the art is the use of virtual Internet Protocol addresses (IPs), or so-called VIPs. In particular, if there are a finite number of possible end locations, and the cardinality of that set is known ahead of time, a proxy can be provisioned with one or more IP addresses per end location. Then, and without modification of the data in Layers 5 through 7, an endpoint can direct traffic to a specific IP or set of IPs, and the proxy can disambiguate the final destination based upon which IP address traffic arrived on. While this method works well when the cardinality of the set is of limited size, it quickly becomes impractical as the number of possible locations increases beyond the set of allocate-able Internet Protocol (IP) addresses on the proxy. The problem is particularly intractable if the proxy VIPs must be reachable on the Internet, and the proxy itself must be able to service the full range of Internet sites. In that case, a single proxy would need to be able to own one half of the allocate-able IP addresses on the Internet just to disambiguate uniquely. Moreover, as new proxies are introduced, the portion of IP addresses on the Internet available to non-proxies would need to shrink to 1/n+1 of the total set, where n is the total number of proxies. This does not work at scale. In these cases, the general method of protocol annotation comes into play. Protocol annotation is the act of modifying the stream of original data to include the destination in OSI Layers 5 through 7. A very common method employed in these use cases is that of the tunnel. When an application tunnels traffic to a proxy, it takes the original traffic, including enough information from Layers 2 through 4, to give the destination address (as well as additional details) accurately, and the proxy embeds that data into OSI Layers 5, 6, 7 (or some combination thereof) of a separate connection maintained with the proxy. The proxy is then able to read the destination information within the tunnel to determine final locations. US 7,346,649 B1 discloses an apparatus providing network content distribution using a personal server approach. A receiving client is provided with a personal server that can select, aggregate, and organize one or more channels of content in a virtual display space of the client. Selection, aggregation, and organization information is stored only locally. Raw data representing content is stored at a logically separate server across a network. US 2016/0337104 A1