Patent ID: 12261847

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

This disclosure describes techniques for nonce-based network security policy enforcement by a DNS, such as a DNS that is part of an enterprise infrastructure and that cooperates with the enterprise security-policy enforcement to provide specific responses to clients that help the enterprise enforce security measures.

The techniques include, by the DNS, receiving a name resolution request from a client computing device and, by the DNS, providing a nonce to the client computing device, wherein a service is configured to authorize a connection request from the client computing device based at least in part on processing the nonce. For example, the DNS may provide the nonce to the client computing device in the form of a nonce address.

The techniques further include a method of validating a connection request from a client computing device, including receiving the connection request, the connection request including a nonce. The techniques further include determining that the nonce is a valid nonce. The techniques further include, based at least in part on determining that the nonce is a valid nonce, authorizing the connection request and disabling the nonce.

Additionally, the techniques described herein may be performed by a system and/or device having non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, performs the methods described herein.

EXAMPLE EMBODIMENTS

In some examples, for dynamic policy-based routing, a client agent such as a virtual private network (VPN) client agent executing on a client computing device selects traffic to be captured, to apply security policies, by matching service name indications in client DNS requests to a list of policies that have been provided to that client agent from a central authority. Based on a match being found, the client agent may reprogram the network stack of the client computing device to direct the traffic to itself. The client agent tunnels such redirected traffic to a security function. Traffic not so redirected, because the service name indication in a DNS request from the client computing device for the traffic does not match one of the policies provided from the central authority, is allowed to be routed directly from the client computing device to the named service. This approach based on client agents may have several disadvantages, including that policy decisions in the operating network are highly decentralized.

In some techniques described herein, such policy decisions may be made in association with a DNS request made by a client computing device. The DNS service, or a service associated with the DNS service, may determine a security policy, if any, to apply to the flow with which the DNS request is associated based at least in part on the indication of a protected service in the DNS request. Based on the security policy, the DNS service, or a service associated with the DNS service, may provide a nonce to the client computing device in response to the DNS request. The client computing device may include the nonce in a connection request to a service, and the service evaluating the connection request may process the nonce to determine what policies to apply to the connection request. Further, the nonce may be an address that points to, for example, a firewall that uses the nonce portion of the address to look up where to forward the traffic (e.g., looks up a server to which the traffic is to be forwarded after inspection). Furthermore, the nonce may thereafter disabled so that it cannot be reused, such as by a device that is able to snoop on the DNS request/response traffic. “Nonce” is a term generally familiar to security specialists, but perhaps not to information technology specialists. “Nonce” was used in the information technology context by Roger Needham, who explained that a “nonce” may be a token added to a message that will be later retuned in a response message, thus proving that the response was generated (partly) by that message. A nonce is generally unguessable and only used once.

Techniques disclosed herein can include capturing traffic in a security function from a computing device, such as a mobile computing device. For example, a DNS server may work together with an enterprise security system and provide addresses that will direct a client's traffic through the system in a secure manner. Those addresses may have a “nonce portion” that makes them unique and usable only once. Moreover, the nonce portion may assist components downstream to identify the traffic for further routing towards where it needs to go.

The DNS response may lead to at least four different types of connections from the client computing device: With a first type, the response allows the client computing device to contact the server directly, every time. In this case, the DNS server may just give the client computing device the server's regular address (no nonces involved). With a second type, the DNS server may allow the client computing device to correspond directly with the server—but only one time. The DNS server may coordinate with the server and agree on a nonce address that the server will accept from the client computing device this time only. For a new conversation, the nonce address will no longer work. With a third type, the DNS server wants the traffic from the client computing device to be routed through the enterprise security infrastructure. The DNS server agrees on a nonce address with the security infrastructure and gives that agreed-upon address to the client computing device. The client computing device uses the address to connect to the security infrastructure, and the security infrastructure that knows about the address will also know how to forward the traffic to the intended server. Because the client computing device sends its traffic using an encrypted tunnel anyway, further encapsulation in a VPN may not be necessary. With a fourth type, most client-server traffic is carried in authenticated and encrypted TLS connections. In those rare occasions where it is not protected automatically, the security infrastructure may wish the traffic to be sent through a VPN tunnel. To use the fourth type in in combination with one or more of the other three options, the client computing device may have a component (client agent) that can intercept the traffic to go through the VPN and send it through that VPN, segregating that VPN traffic from the traffic according to the first type, the second type and the third type.

Thus, for example, a client agent such as a VPN client agent may not be necessary for applying policy-based dynamic routing. The techniques may enable an enterprise to control and direct the capture of traffic from a client computing device, such as a mobile client computing device used by an enterprise worker, without direct involvement of that worker.

For dynamic policy-based routing, in many examples, a client agent selects what traffic to capture by matching client DNS requests to a list of policies that are downloaded into that agent. Depending on whether a match is found, the agent may reprogram the network stack to direct that traffic to itself. The agent may then tunnel the traffic to a security function. Alternatively, traffic can be allowed to be routed directly to the named service.

The DNS server (part of the enterprise) should securely know the identity of the client computing device. Unencrypted port 53 traffic does not allow that, because it could be generated anywhere and intercepted by anyone. So, for example. DoH or DoT may be used, with the DNS server verifying the identity of the client computing device before responding to requests. Alternatively, a DNS server that cannot verify the identity of a client computing device may direct all of the client computing device's traffic through the corporate security infrastructure. A method to capture traffic may rely on combining a central DNS server capable of capturing end-to-end encrypted traffic, that is integrated with a central enterprise policy service and, optionally, one or more centrally hosted destination services. In accordance with some described techniques, when a client computing device requests name resolution from the DNS service, the DNS service, sometimes in collaboration with an enterprise policy manager, may determine how traffic from the client computing device is to be routed (such as directly, or via an enterprise security function). The DNS service may set up the security function, if necessary, and then send a short-lived address—a nonce address—in a DNS response. The nonce address may allow the client computing device, and only the client computing device, to reach the service, possibly via the security function, for a limited time.

Thus, for example, flows may be captured that are to be regulated by a security function. The DNS request may be recognized by a security function, and then if a flow is to be captured, the requested name may be mapped to a dynamically allocated IP address from a destination function and a route installed in the client computing device that points to the destination function, optionally by way of a secured tunnel. This can simplify the processing by the client computing device and provide a robust and flexible solution.

More specifically, a network-based function may work in concert with a network-based DNS, posture- and policy service, zero, one or more (in-line) security services and an optional client agent to tunnel traffic to the security functions. A technique may include capturing a client computing device's DNS request for the server in the central network function. The identity of the client computing device may also be captured. By policy, it may be determined if the flows to that server, perhaps from the specific client or from client similarly characterized, are to be captured by a security function. If the policy service indicates flows do not need to be captured, the DNS may return the public IP address of the requested server in its response, to allow the client computing device to directly engage with the server across the Internet.

When flows are to be captured, the DNS may return an address that routes to an enterprise security function, possibly via a protective tunnel, where the traffic can be inspected before forwarding to the server. Alternatively, or additionally, an address can be returned that a virtual private cloud ingress point, load balancer or other multihomed service can use to deliver traffic to the desired service. This may free the ingress point from having to interpret service names.

The DNS server for an enterprise device may be an enterprise DNS server that uses an enterprise policy or interacts with an enterprise policy server to provide the DNS response. The DNS request and DNS response may be end-to-end encrypted, to minimize the possibility of tamper, such as by DoH or by DoT. The client computing device identity may be captured by the DNS server, allowing the use of user- or client-specific policies (or, in some examples, policies specific for categories of clients). Using enterprise policy (possibly client-specific), the DNS server can determine how traffic between client and (cloud) server should be treated and respond appropriately.

When the client is to be allowed to communicate to the server directly, the DNS server may simply return the IP address of that server. Alternatively, for sensitive enterprise servers that should only be addressed by authorized clients, the DNS server may return a nonce address to those requesting authorized clients. The DNS server can also return a nonce address that indicates an enterprise security function, or routes through a virtual private cloud (VPC) ingress point or load balancer. After passing through that function, traffic may be forwarded to the requested server. That routing may use a tunnel between the client and the security function. In that case, the nonce address may not be a routable address (preventing it from being used outside the tunnel). The DNS server and the security function may have previously agreed on these nonce addresses, so that the security function can recognize the address for security and server-forwarding purposes. The nonce address can be client specific. It may be used as a one-time permission for that client to access the service. As soon as a client has started using the nonce address, the nonce address may be disabled so that other clients are no longer able to connect using that same address.

A nonce address may be an address used for a specific purpose and valid for a limited time. A name server can map a name to a nonce address that can only be used by a specific client and only once. Or a name server can map to a nonce address that can be used by multiple clients in a particular category and for a period of, for example, five minutes. A nonce address may not be guessed. Without the assistance of the name server, a useful nonce address cannot be obtained.

IPv6 addresses may be suited to be used as nonce address. The size of an IPV6 address being 128 bits allows only half of those bits to be used to route packets to their destination—the routing part. The other half may be available to identify a service, and/or a purpose, at that destination—the nonce part. That purpose may be, for example, the connection of a particular authorized client to the service. Or it may be the connection of clients via some security functions to the service. Nonce addresses in this latter category can be devised not to work for direct connections. A nonce address intended for routing traffic through a network-based security function can be made to route to that security function only, while the nonce part can be used by the security function to look up what security functions should be provided and where the traffic should be forwarded subsequently. Nonce addresses can also be used to tell an intermediate function, such as a load balancer, how to forward traffic to the correct service in, for example, a VPC.

If nonce addresses are used to address a service directly, then some coordination may be employed between the DNS server giving them out and the service being addressed. Alternatively, the nonce address can be used to reach a gateway that forwards the traffic to the correct service. In this latter case, in some examples, only the gateway may be involved with nonce-address assignment and interpretation.

This coordination can be explicit—that is, the service (or gateway) and the DNS server may exchange information to accomplish the coordination—or the coordination may be implicit, by using an algorithm shared by the service and the DNS server. An example of such an algorithm can be that the two entities share a key and an initial address to be given out. They can each independently calculate the next address by applying a function with the shared key and the previous address as inputs. This function may not have to be cryptographically strong—real verification is still carried out in the TLS handshake and subsequent client authentication. Instead, the function may be carried out relatively inexpensively and can also thus be resistant to distributed denial of service (DDOS) attacks.

If, on the other hand, nonce addresses are used to direct clients through a security function before forwarding traffic to the destination service, then more explicit agreement between the security function and the DNS server may be carried out. The DNS server, as the manager of the enterprise security profile, may identify what security requirements are to be used for a specific client-server connection. The DNS server may set this up in the security-function infrastructure and set up the nonce address to be used for that connection. The DNS server may then return the DNS resolution to the requesting client to include that same nonce address.

Flow can therefore be captured in a security function (e.g., cloud) as a side-effect of resolving the name of the (cloud) application through a centralized DNS service. This DNS service can be part of a cloud-based security function. The DNS service may provide nonce-addresses with the benefit of ensuring that the addresses are valid for a specific purpose and possibly for only a specific client, allowing the addresses to double as directives for a security function as to how to treat and forward the traffic, and limiting the lifetime of the addresses, so caching of addresses may be better controlled. A client route may be configured on a client computing device that directs flows to a pre-established tunnel and DNS resolving names of cloud applications that point to the IP address space associated with that tunnel.

FIG.1is an architecture diagram illustrating an example network100in which a DNS service102may determine a security policy is to be applied to a flow with which a DNS request made by a client computing device104via an enterprise network105is associated, based at least in part on the indication of a protected service106in the DNS request. For example, the DNS service102may refer to an enterprise policy service108to determine a security policy is to be applied to the flow with which the DNS request made by the client computing device104via the enterprise network105is associated, based at least in part on the indication of the protected service106in the DNS request.

The DNS service102may respond to the DNS request made by the client computing device104with an indication that the security policy is to be applied to the flow with which the DNS request made by the client computing device104is associated. For example, the DNS service102may resolve a domain name in the DNS request to an address associated with an intermediate service110. The intermediate service110may be a security service or other service that operates to function as a gateway to the protected service106.

In addition, the DNS service102may respond to the DNS request made by the client computing device104with a nonce. A nonce is an arbitrary number that can be used just once for communication. A nonce is often a random or pseudorandom number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks. In the context of the network100, the nonce may be a number that is processed by the intermediate service110in determining to authorize a connection request from the client computing device104to the protected service106. That is, the client computing device104includes the nonce, received from the DNS service102as part of the response by the DNS service102to a DNS request, in the connection request to the protected service106based at least in part on processing the nonce. The intermediate service110validates the connection request from the client computing device104to the protected service106by, at least in part, determining if the nonce is a nonce that corresponds to a valid connection request by the client computing device104to the protected service106.

In one example, based at least in part on the DNS request from the client computing device104, the DNS service102may provide the nonce to both the client computing device104as at least a part of the response to the DNS request from the client computing device104, as well as providing the nonce to the intermediate service110. The intermediate service110may then use the nonce provided by the DNS service102to validate the connection request from the client computing device104to the protected service106by in part, for example, comparing the nonce provided by the DNS service102to the nonce provided by the client computing device104as part of the connection request from the client computing device104to the protected service106.

In another example, based at least in part on the DNS request from the client computing device104, the DNS service102may provide the nonce to the client computing device104as at least part of the response to the DNS request from the client computing device104, but does not provide the nonce to the intermediate service110. The DNS service102and the intermediate service110may coordinate to agree on the nonce. This coordination can be explicit. For example, the DNS service102and the intermediate service110may exchange information to coordinate to agree on the nonce. As another example, the coordinate can be implicit, such as by using an algorithm commonly known by both the DNS service102and the intermediate service110. An example of such an algorithm includes the DNS service102and the intermediate service110agreeing on a key and an initial nonce. The DNS service102and the intermediate service each independently calculate, using the commonly known algorithm, the next nonce by applying a function with the shared (secret) key and the previous nonce as inputs. For example, the intermediate service110may have an associated nonce generation and/or storage function112The function may not be cryptographically strong. For example, verification may still be carried out in a transport layer security (TLS) handshake and subsequent client authentication.

In some example, the nonce may utilized by the intermediate service110, such as a security service, to determine what policies to apply to traffic from the client computing device104destined to the protected service106. For example, there may be more explicit agreement between the DNS service102and the intermediate service110. For example, the DNS service102, as manager of the enterprise security profile, may identify what security requirements are to be applied for the connection between the client computing device104and the protected service106. The DNS service102may provide an indication of the security requirements to the intermediate service110along with the nonce. When the client computing device104provides, to the intermediate service110, the connection request to the protected service106, the intermediate service110may process the nonce received in the connection request to determine what security policies to apply to the connection between the client computing device104and the protected service106.

In another example, the DNS service102may determine that a security policy is not to be applied to a flow with which a DNS request made by a client computing device104via the enterprise network105is associated, based at least in part on the indication of an unprotected service114in the DNS request. For example, the DNS service102may refer to the enterprise policy service108to determine that a security policy is not to be applied to the flow with which the DNS request made by the client computing device104via the enterprise network105is associated, based at least in part on the indication of the unprotected service114in the DNS request.

In this example, the DNS service102may resolve a domain name in the DNS request to an address associated with the unprotected service114. The DNS service102may provide, to the client computing device104, the address associated with the unprotected service114. The DNS service102may not provide, to the client computing device104, a nonce for the client computing device to provide to as part of the connection request from the client computing device104to the unprotected service114. For example, since a security policy is not to be applied to a flow to the unprotected service114, the nonce may not be required to be provided by the client computing device104making a connection request to initiate a connection to the unprotected service114.

In some examples, the client computing device104may still include a client agent116that regulates access to at least some protected services. In some examples, the enterprise may install a policy in the client agent116to cause the client agent116to capture flows to the at least some protected services. The enterprise may dynamically configure the client agent116by, for example, downloading new or updated policy rules into the client agent116.

In a specific example of use of the example network100, the client computing device104issues a DNS request (1) via the enterprise network105. The DNS request includes the domain name of the protected service106, to be resolved by the DNS service102into an IP address. The DNS request may be formatted and defined, for example, in accordance with RFC 1035, “Domain Names—Implementation and Specification,” dated November 1987. The DNS request continues on (2), via the enterprise network105, to the DNS service102.

The connection between the client computing device104and the DNS service102may be a secure end-to-end encrypted connection. For example, the secure end-to-end connection may be a DoH connection in accordance with RFC 8484, “DNS Queries over HTTPS (DoH),” dated October 2018. DoH is a protocol for sending DNS queries and getting DNS responses over HTTPS. In accordance with DoH, each DNS query-response pair is mapped into an HTTP exchange. DoH establishes default media formatting types for requests and responses using normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer. DoH also aligns itself with HTTP features such as caching, redirection, proxying, authentication, and compression. The integration with HTTP provides a transport suitable for both existing DNS clients and native web applications seeking access to the DNS.

As another example, the connection between the client computing device104and the DNS service102may be a secure end-to-end encrypted connection that is a DoT connection in accordance with RFC 7858, “Specification for DNS over Transport Layer Security (TLS),” dated May 2016. DoT uses DNS over TLS on a well-known port. By establishing a connection over a well-known port, clients and servers expect and agree to negotiate a TLS session to secure the channel.

The DNS service102forms a DNS response that includes the IP address corresponding to the intermediate service110and a nonce for use by the client computing device104to include as part of a connection request to the protected service106. The DNS service102may form a response that is formatted and defined in accordance with RFC 1035. The DNS service provides (3) the DNS response, which is provided (4) to the client computing device104via the enterprise network105.

In some examples, the DNS service102also provides (3a) the nonce to the intermediate service110. In other examples, the intermediate service110independently generates the nonce, having coordinated with the DNS service102so that the nonce that the intermediate service110independently generates corresponds to the nonce that the DNS service102includes in the DNS response that goes to the client computing device104.

In some examples, the DNS service102includes the nonce as part of the address, such as an IP address, that the DNS service102provides to the client computing device104. For example, the IP address may be an IPV6 address formatted in accordance with RFC 4291. “IP Version 6 Addressing Architecture,” dated February 2006. The DNS service102may include the nonce as the lower 64 bits of the IPV6 address, whereas the upper 64 bits of the IPV6 address may be utilized by the network100for routing.

The client computing device104includes (5) the nonce as part of a connection request to the protected service106, which is provided (6) via the enterprise network105. The destination address that the client computing device104includes in the connection request is the address of the intermediate service110. This is due to the DNS service102having provided the address of the intermediate service100to the client computing device104in response to the DNS request made by the client computing device104to resolve the name of the protected service106.

The intermediate service110receives the nonce as part of the connection request by the client computing device104to connect to the protected service106. The intermediate service110evaluates the nonce received as part of the connection request to determine whether to allow the connection request to the protected service106. For example, the intermediate service110may compare or otherwise evaluate the nonce received as part of the connection request relative to a nonce the intermediate service102received from the DNS service102based at least in part on the DNS request provided from the client computing device104to resolve the name of the protected service106. As another example, the intermediate service110may compare or otherwise evaluate the nonce received as part of the connection request relative to a nonce the intermediate service110independently generated or is generated by an associated nonce generation service112. As part of the evaluation of the received nonce, the intermediate service110may evaluate whether the received nonce had been previously used and, thus, would be invalid to be used subsequent to the initial use of the nonce. For example, the intermediate service110may keep a record of previously used nonces, and the intermediate service110may compare the received nonce to its record of previously used nonces.

When the intermediate service110determines the nonce received from the client computing device104as part of a connection request to the protected service106indicates the connection request is a valid connection request, the intermediate service110provides (7) the connection request to the protected service106. The protected service106responds (8) to the connection request, such as at least providing an acknowledgement of the connection request to the intermediate service110. The intermediate service then provides (9) a response, which may include the acknowledgement, via the enterprise network105to be provided (10) to the client computing device104. The client computing device104, having received the response, connects to the protected service106, such as to initiate a flow of data traffic to the protected service106.

In another example, the DNS request the client computing device104provides (1), which is provided (2) to the DNS service102via the enterprise network105, is a DNS request to resolve the name of the unprotected service114. The DNS service102provides (not shown inFIG.1) a response, to the client computing device104via the enterprise network, that resolves the name of the unprotected service114to the address of the unprotected service114. The client computing device104thereafter provides (11) a connection request to the unprotected service114via the internet118. The unprotected service114acknowledges the connection request to the client computing device104, which thereafter connects to the unprotected service114, such as to initiate a flow of data traffic to the unprotected service114.

In some examples, in responding to the DNS request provided from the client computing device104, the DNS service102includes the nonce as part of an IPV6 destination address that the DNS service102provides, corresponding to the intermediate service110.FIG.2illustrates an example format200for such an IPV6 destination address that includes the nonce. Referring toFIG.2, the example format200includes a routing part202and a nonce part204.

The routing part202includes the most significant eight octets (octets 8 to 15) of the example format200. The eight-octet routing part202of the IPV6 format200is sufficient to be used to route packets from the client computing device104to the intermediate service110. The nonce part204includes the least significant eight octets (octets 0 to 7) of the example format200. The eight-octet nonce part204of the IPV6 format200are determined by the DNS service102and used by the client computing device104to identify a service and/or a purpose to the intermediate service110in the connection request. For example, the eight-octet nonce part204of the IPV6 format200may identify a purpose to connect the client computing device104to the protected service106. As another example, the intermediate service110may be a security service, and the eight-octet nonce part204of the IPV6 format200may identify security functions for the intermediate service110to apply to traffic originating at the client computing device104and destined to the protected service106.

The DNS service102may generate the routing portion202of the IP address format to avoid direct connection to the protected service106. For example, the DNS service102may generate the routing portion202of the IP address format200for a connection intended to be regulated by a network-based security function, such as the intermediate service110performing the security function, to route traffic to that security function only and not to the protected service106as the initial destination. The security function may process the nonce part204of the IP address format200to determine what security functions to perform and the destination service to which to forward the traffic (e.g., the protected service106) after performing the security functions.

In other examples, the intermediate service110may be performing other types of functions in addition to or instead of performing security functions. For example, the intermediate service110may be performing a load balancing function. In this example, the intermediate service may process the nonce part204of the IP address format200to determine how to forward traffic to the appropriate service in, for example, a virtual private cloud (VPC) that includes multiple services.

FIG.3is a flowchart illustrating an example process300carried out by the client computing device104, to initiate and carry out a connection with the protected service106. For example, the protected service106may be protected by enterprise security functions performed by the intermediate service110.

At302, the client computing device104makes a DNS request to the DNS service. The client computing device104makes the DNS request to the DNS service102, with the client computing device104including the domain name of the protected service106in the DNS request. At304, the client computing device104receives a response, corresponding to the DNS request, from the DNS service102. The response includes, in one example, an IPV6 address that includes both a routing part and a nonce part.

In other examples, the client computing device104receives a response in which the nonce is not part of the received address but, rather, is an adjunct to the received address. That is, in these other examples, the client computing device104will not include the nonce as part of the destination address when the client computing device104provides a connection request to the protected service106, but the nonce may be included in a different field of the response to the DNS request other than the received address.

At306, the client computing device104provides the connection request, including the address (and the nonce separately, if the DNS service102did not provide the nonce as part of the address) received from the DNS service102. Due at least in part to the address provided by the DNS service102pointing to the intermediate service110, the connection request is routed to the intermediate service110.

At308, the client computing device104receives a response to the connection request that the client computing device104provided. In some examples, the client computing device104participates in a handshake exchange of messages to establish the connection with the protected service106. At310, the client computing device104sends data traffic over the thus-established connection.

With respect to the process300, in some examples due to the DNS service102embedding the nonce in the IP address it provides, the client computing device104may not even be aware that the response from the DNS service102includes the nonce. Furthermore, when the client computing device104sends the connection request and includes the IP address, with embedded nonce, that was provided from the DNS service102, the client computing device104may not even be aware that the IP address includes the nonce. Yet further, for example, when the client computing device104sends traffic destined to the protected service106over a connection, the client computing device104may not even be aware that the routing part202of the IP address is used to route the traffic to the address of the intermediate service110and that the nonce is included as a nonce part204of the IP address.

FIG.4is a flowchart illustrating an example process400carried out by the DNS service102to resolve a request from the client computing device104for an address of the protected service106. At402, the DNS service102receives a DNS request from the client computing device104. The DNS request includes an indication of the domain name of the protected service106.

At404, the DNS service102determines at least one enterprise security policy associated with the client computing device104and the protected service106. For example, a network administrator may have used a network management platform and/or portal to configure the enterprise security policies. In some examples, the network administrator using a network management platform and/or portal in this way may not be much different, if at all, from using the network management platform and/or portal to configure enterprise security policies for download into the client agent116that may be executed by the client computing device104.

At406, the DNS service102sends, to the client computing device104, a response to the DNS request that was sent from the client computing device104. The DNS service102includes, in the response, the address to route to the intermediate service110. The DNS service102also includes a nonce corresponding to the determined enterprise security policy as well as including, in the nonce, an indication of the protected service106. In some examples, the DNS service102provides the nonce as part of an IPV6 (or other format) address. That is, the DNS service102may provide a routing part202of the IPV6 address with which data traffic from the client computing device104may be routed to the intermediate service110. Additionally, the DNS service102may provide a nonce part204of the IPV6 address that may include the indication of the determined enterprise security policy as well as an indication of the protected service106.

FIG.5is a flowchart illustrating an example process500carried out by the intermediate service110to process a connection request provided by the client computing device104. At502, the intermediate service110receives a connection request, including a nonce, from the client computing device104. For example, the client computing device104may include the nonce as part of a destination IPv6 (or other format) address in the connection request. That is, the client computing device104may provide a routing part202of the IPV6 address with which data traffic from the client computing device104may be routed to the intermediate service110. Additionally, the client computing device104may provide a nonce part204of the IPV6 address that includes the indication of the determined enterprise security policy as well as an indication of the protected service106. The IPV6 address having the routing part202and the nonce part204may have been received by the client computing device104from the DNS service102in response to a DNS request from the client computing device104.

At504, the intermediate service100determines that the nonce included in the connection request from the client computing device104is valid. For example, the DNS service102may have provided the nonce to the intermediate service110at the time the DNS service102responded to a DNS request from the client computing device104. Furthermore, intermediate service110may not have processed that same nonce previously. For example, the nonce may not be a nonce that the intermediate service110has tracked as being previously used. Yet still, the intermediate service110may determine that a time at which the connection request, including the nonce, is received from the client computing device, is within a time period associated with the intermediate service110receiving the nonce from the DNS request. On the other hand, if the intermediate service110does not determine that the nonce included in the connection request from the client computing device104is valid, the intermediate service may not proceed to operation506of the process500, for the connection request received at operation502of the process500.

At506, the intermediate service110determines the service, if any, to which the nonce corresponds. More particularly, the intermediate service110determines that the nonce corresponds to the protected service106. For example, the nonce may include an index into a table of protected services, and the intermediate service110indexes into the table with the included index to obtain, from the indexed entry in the table, a value for the indexed entry that is an indication of the protected service106. The intermediate service may have populated the index entry with the indication of the protected service106based at least in part upon the notification of the nonce from the DNS service102.

At508, the intermediate service110determines the security policy, if any, indicated by the nonce. For example, the DNS service102, upon generation of the nonce, may have informed the intermediate service110of the nonce along with at least one security policy to apply to a connection request that includes the nonce. The intermediate service110may have stored an indication of the at least one security policy in a manner that the indication of the at least one security policy could be determined upon receipt of the connection request including the nonce. As another example, the intermediate service110may implicitly apply one or more security policies to the connection request even if a security policy is not explicitly indicated by or otherwise corresponds to the nonce.

At510, the intermediate service110provides the connection request to the service to which the intermediate service110has determined the nonce corresponds (the protected service106, since the connection request is allowed to be provided consistent with the security policy. At512, the intermediate service110disables the nonce included in the connection request, so that the nonce cannot be subsequently reused. This will, for example, prevent an eavesdropper of the connection request from the client computing device104from accessing the protected service106by reusing the nonce included in the connection request from the client computing device. For example, the intermediate service110may track the nonce as having been used in a manner that the intermediate service110can determine, when processing a subsequent connection including the same nonce, that the subsequent connection request is invalid.

FIG.6illustrates an example computer architecture for a computer600capable of executing program components for implementing the functionality described above. The computer architecture shown inFIG.6illustrates an architecture of a server computer, workstation, desktop computer, laptop, tablet, network appliance, e-reader, smartphone, network switch, or other computing device, and can be utilized to execute any of the software components presented herein. The computer600may, in some examples, correspond to a network infrastructure device discussed herein.

The computer600includes a baseboard602, or “motherboard,” which may be a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (“CPUs”)604operate in conjunction with a chipset606. The CPUs604can be, for example, standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computer600.

The CPUs604perform operations by transitioning from one discrete, physical state to the next through the manipulation of switching elements that differentiate between and change these states. Switching elements generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide an output state based on the logical combination of the states of one or more other switching elements, such as logic gates. These basic switching elements can be combined to create more complex logic circuits, including registers, adders-subtractors, arithmetic logic units, floating-point units, and the like.

The chipset606provides an interface between the CPUs604and the remainder of the components and devices on the baseboard602. The chipset606can provide an interface to a RAM608, used as the main memory in the computer600. The chipset606can further provide an interface to a computer-readable storage medium such as a read-only memory (“ROM”)610or non-volatile RAM (“NVRAM”) for storing basic routines that help to startup the computer600and to transfer information between the various components and devices. The ROM610or NVRAM can also store other software components necessary for the operation of the computer600in accordance with the configurations described herein. As illustrated inFIG.6, the ROM610or NVRAM can also store data usable by the computer600to generate and/or process attestation information in messages exchanged among the computer600and other devices. In other examples, this data may be stored elsewhere, such as in RAM608.

The computer600can operate in a networked environment using logical connections to remote computing devices and computer systems through a network. For example, the chipset606can include functionality for providing network connectivity through a Network Interface Controller (NIC)612, such as a gigabit Ethernet adapter. The NIC612can connect the computer600to other computing devices over a network. It should be appreciated that multiple NICs612can be present in the computer600, connecting the computer to other types of networks and remote computer systems. In some instances, the NICs612may include at least one ingress port and/or at least one egress port. An input/output controller616may be provided for other types of input/output.

The computer600can be connected to a storage device618that provides non-volatile storage for the computer. The storage device618can store an operating system620, programs622, and data624, for example. The storage device618can be connected to the computer600through a storage controller614connected to the chipset606. The storage device618can include one or more physical storage units. The storage controller614can interface with the physical storage units through a serial attached SCSI (“SAS”) interface, a serial advanced technology attachment (“SATA”) interface, a fiber channel (“FC”) interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

The data624may include, for example, a table of protected services, where the intermediate service110may index into the table with an index included in a nonce to obtain, from the indexed entry in the table, an indication of a protected service to which the intermediate service110is to forward traffic over a connection from a client computing device that provided the nonce. The intermediate service110may have populated the index entry with the indications of the various protected services based at least in part upon notification of nonces from the DNS service102. The data624may also or instead include a list of nonces that have been previously used so that, for example, the intermediate service110can reject a connection request that includes a nonce that is indicated by the data624as having been previously used.

The computer600can store data on the storage device618by transforming the physical state of the physical storage units to reflect the information being stored. The specific transformation of physical state can depend on various factors, in different embodiments of this description. Examples of such factors can include, but are not limited to, the technology used to implement the physical storage units, whether the storage device618is characterized as primary or secondary storage, and the like. For example, the computer600can store information to the storage device618by issuing instructions through the storage controller614to alter the magnetic characteristics of a particular location within a magnetic disk drive unit, the reflective or refractive characteristics of a particular location in an optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this description. The computer600can further read information from the storage device618by detecting the physical states or characteristics of one or more particular locations within the physical storage units.

In addition to the storage device618described above, the computer600can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data, including data to generate and/or process attestation information. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the computer600.

While the invention is described with respect to the specific examples, it is to be understood that the scope of the invention is not limited to these specific examples. Since other modifications and changes varied to fit particular operating requirements and environments will be apparent to those skilled in the art, the invention is not considered limited to the example chosen for purposes of disclosure and covers all changes and modifications which do not constitute departures from the true spirit and scope of this invention.

Although the application describes embodiments having specific structural features and/or methodological acts, it is to be understood that the claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are merely illustrative of some embodiments that fall within the scope of the claims of the application.