JP2018514956A - Apparatus and method for using certificate data to route data - Google Patents

Abstract

A method for routing data over a network receives a session request from a client node accessing at least one node in a local network having a plurality of nodes. The method also receives a client certificate (eg, a digital certificate that is at least partially specified by a known standard, such as the “X509 standard”) from the client node. The client certificate has client information that specifies at least one node that receives packets from the client node. The method then performs the authentication process using the client certificate. If the client node is authenticated by the authentication process, the method routes the data packet from the client node to at least one node in the local network as specified by the client information in the client certificate.

Description

RELATED APPLICATIONS This application is based on US patent application Ser. No. 14 / 497,954 filed Sep. 26, 2014, entitled “NETWORK PACKET FLOW CONTROLLER”, agent serial number 4094/1001, Which relates to the inventors Melampy, Baj, Kaplan, Kumar, Penfield and Timmons, the entire disclosure of which is incorporated herein by reference.

  This application is also US patent application Ser. No. 14 / 562,917, filed Dec. 8, 2014, entitled “Stateful Load Balancing in a STATEMENT NETWORK”, Acting Name. Related to Person Number 4094/1002, Inventors Timemons, Baj, Kaplan, Melampy, Kumar, and Penfield, the entire disclosure of which is incorporated herein by reference.

  This PCT application is filed on US patent application Ser. No. 14 / 660,500, filed Mar. 17, 2015, entitled “Apparatus and Method For Using Certificate Data to Route Data”. USING CERTIFICATE DATA TO ROUTE DATA), Attorney Docket No. 4094/1005, inventors Kumar, Timmons and MeLampy, all of which are incorporated herein by reference in their entirety.

TECHNICAL FIELD The present invention relates generally to network devices, and more particularly to security for network routing devices.

  The Internet Protocol (“IP”) is used as the de facto standard for transferring data messages (“datagrams”) between network devices connected to the Internet. To that end, IP supplies datagrams in the form of one or more data packets via a series of internet devices, eg via routers and switches. Each packet has two main parts: (1) a payload having information to be transmitted (eg text data, graphic data, audio data or video data), and (2) (one or more) "IP header", which has the address of the network device receiving the packet ("destination device"), the identifier of the network device sending the packet ("originating device"), and other data for routing the packet Known as the header. Thus, many people describe the packet as an example of a traditional traditional letter that uses general mail / first class mail. That is, the letter functions as a payload, and the sealed letter indicating the sender address and the destination address functions as an IP header.

  Hackers frequently attempt to perform illegal operations by accessing third party Internet devices, such as application services in a data center. A large amount of data can be leaked due to such violations. Data breaches have led to widespread scams that can cost billions of dollars.

Summary of Various Embodiments According to one embodiment of the present invention, a method for routing data over a network includes a client accessing at least one node in a local network having a plurality of nodes. Receive a session request from a node. The method also receives a client certificate (eg, a digital certificate that is at least partially specified by a known standard, such as the “X509 standard”) from the client node. The client certificate has client information that specifies at least one node that receives packets from the client node. The method then performs an authentication process using the client certificate. If the client node is authenticated by the authentication process, the method routes the data packet from the client node to at least one node in the local network as specified by the client information in the client certificate.

  If the authentication process fails to authenticate the client node, the method can reject the client node. For example, the method can effectively block a client node's packets from accessing other nodes in the local network (ie, the method simply forwards packets received from the client node). is not).

  The illustrated embodiment routes data packets using client information for determining the identifier of at least one node in the local network that receives the data packets. Therefore, when routing is performed, it can be considered that the client node is permitted to access at least one node.

  Among other things, the client information includes: a) identification information identifying the client node, b) policy information that gives the client node a set of privileges when accessing at least one node in the local network, or both client information and policy information Can be included. Thus, the data packet can be routed as specified by one or both of the identification information and policy information.

  A local network (eg, a local area network) can have an edge router that receives session requests, receives client certificates, retrieves client information, and / or routes data packets. The local network can also include other nodes. For example, at least one node can include an application server.

  Virtual connections formed by routing can use different approaches. For example, the virtual connection can maintain a static connection between a receiving node of the local network that receives the session request and at least one node in the local network. This static connection exists only in the local network. In that case, routing can include routing of data packets from the client along a static connection. Thus, in such an embodiment, it is not expected that a well-known handshake process will be performed between the client node and at least one node in the local network during the session.

  However, other embodiments may not use the static connection described above. For example, the method may allow an initial handshake process between the client node and at least one node before receiving the certificate, and if the client node is authenticated by the authentication process Can allow the completion of the final handshake process between the client node and at least one node.

  Among other things, the authentication process can receive a login ID and password for the guest user and can verify that the login ID and password are valid for access within the local network. Some embodiments may determine a client device identifier (eg, the MAC address of the client device) that identifies the client node device, and use the client device identifier and client certificate to perform the authentication process. be able to.

  According to another embodiment, a network routing device for routing data received over a network comprises: a) from a client node accessing at least one node in a local network having a plurality of nodes And b) an interface for receiving a client certificate from the client node. The client certificate has client information that specifies at least one node that receives packets from the client node. The network routing device is configured to retrieve client information from the client certificate and use the client information to perform an authentication process and is connected to the interface to work properly. It also has an authenticator. Further, the network routing device is configured to determine from the authenticator whether the client node has been authenticated by the authentication process, and a router connected to the authenticator to work properly is also provided. Have. Thus, the router is configured to route data packets from the client node to at least one node in the local network as specified by the client information in the client certificate when the client node is authenticated. Yes.

  According to yet another embodiment, a method for routing data across a network receives a session request from a client node accessing at least one node in a local network having a plurality of nodes, and the client Receive a client certificate from a node. The client certificate has client information that specifies at least one node that receives packets from the client node. The method retrieves client information from the client certificate and facilitates at least restrictive access to at least one node based on the client information in the client certificate.

  The illustrated embodiment of the invention is implemented as a computer program product having a computer usable medium and computer readable program code on the medium. The computer readable code can be read and utilized by a computer system according to conventional processes.

  Those skilled in the art will more fully appreciate the advantages of the various embodiments of the present invention from the “Description of Illustrated Embodiments” section, described in conjunction with the drawings briefly described below. Becomes clear.

1 schematically illustrates a virtual prior art network in which the illustrated embodiment of the present invention may be used. Fig. 4 schematically illustrates prior art message fragmentation that may be used by the illustrated embodiment of the present invention. 1 schematically illustrates a general prior art Internet in which the illustrated embodiment of the present invention may be implemented. Fig. 2 schematically illustrates a more specific type of Internet in which the illustrated embodiment of the invention can be implemented. 1 schematically illustrates various portions of an edge router configured in accordance with an illustrative embodiment of the invention. Fig. 4 shows a process of accessing a server according to an illustrative embodiment of the invention. 2 illustrates an example of a digital certificate created in accordance with the illustrated embodiment of the present invention. 2 illustrates an example of a digital certificate created in accordance with the illustrated embodiment of the present invention.

  In the illustrated embodiment, the network device routes data messages coming from distant clients locally based on client-specific information in the client's digital certificate. To that end, the client's digital certificate includes additional information, such as information identifying the client's identifier, and its unique client policy / authorization when accessing a particular device in the local network of the routing network device. And have.

  Thus, after client verification / authentication, the network device routes client packets within its local network (eg, its local area network) according to the client information in the client digital certificate. Thus, the client can only access the preselected network device as specified by the client information in the digital certificate. In addition, clients can only have certain privileges on their preselected network devices based on policy information in the client certificate. The illustrated embodiment will be described in detail below.

Network The illustrated embodiment is preferably implemented in a conventional computer network. In particular, the network includes at least two nodes and at least one link between the nodes. Nodes can include computing devices (sometimes referred to as hosts or devices) and routers. Computers include personal computers, smartphones, television set-top boxes, automated teller machines (ATMs), and many other types of devices including processors and network interfaces. The link includes wired and wireless connections between node pairs. In addition, nodes and / or links can be implemented entirely as software, for example in virtual machines, software defined networks (SDN) and network function virtualization (NFV). Can be implemented using. Many networks include switches, most of which are transparent with respect to this discussion. However, some switches also perform routing functions. For the purposes of this discussion, such a routing switch is considered a router. The router will be described below.

  A node can be directly connected to one or more other nodes, each via a separate link. For example, FIG. 1 schematically shows that node A is directly connected to node B via link 1. In a given network (eg, within a local area network), each node has a unique network address to facilitate data transmission and reception. The network includes all nodes that are addressable within the network according to the network addressing scheme and all links that interconnect the nodes to communicate according to the network addressing scheme. For example, in FIG. 1, node A, node B, node C to node F, and all links 1 to 8 form one network 100 together. For simplicity, the network can be shown as one cloud or contained within one cloud. However, the absence of a cloud does not mean that a collection of nodes and links is not a network. For example, one network can be formed from a plurality of relatively small networks.

  Each node can initiate communication with other nodes via the network, and each node can receive communications initiated by other nodes via the network. For example, a node transmits / transmits data (message) to a directly connected node (adjacent node) via a link interconnected with the adjacent node. Can be transferred / transmitted. The message includes the network address of the sending node (“source address”) and the intended recipient network address (“destination address”). A sending node may send a message to a non-adjacent node via one or more other intervening nodes. For example, node D can send a message to node F via node B. Using well-known networking protocols, the node (s) that exist between the source node and the destination node forward the message until the message reaches its destination node. Thus, in order to operate properly, the network protocol allows each node to learn or discover the network addresses of non-adjacent nodes in that network.

  The node communicates via a network according to a protocol, for example, according to a known Internet protocol (IP) and a transmission control protocol (TCP). The protocol is typically implemented by layered software components and / or hardware components, for example, according to the well-known 7-layer Open System Interconnect (OSI) model. As an example, IP functions at OSI layer 3 (network layer), while TCP functions mostly at OSI layer 4 (transport layer). Each layer performs a logical function and also abstracts the layers below itself, thus hiding the details of the lower layers.

  For example, if layer 3 (data link layer) cannot process one large message in a single transmission, layer 3 can perform fragmentation of the message into multiple smaller packets. FIG. 2 schematically shows a large message 200 divided into a plurality of parts 202, 204, 206, 208, 210 and 212. In this case, each portion 202-212 can be transmitted as a separate packet, exemplified by packet 214. Each packet includes a payload (body) portion illustrated by payload 216 and a header portion illustrated by reference number 218. The header portion 218 is needed or desired for (1) routing the packet to its destination, (2) reassembling the packet of the message, and (3) other functions provided according to the protocol. Contains information such as the source address, destination address and packet sequence number of the packet. In some cases, a trailer portion is also added to the payload, eg, to perform a checksum of the entire payload or packet. Not all packets of a message need to be sent along the same path. That is, it is not necessary to pass through the same node in the route to the common destination of these packets. Although IP packets are formally referred to as IP datagrams, it is noted that they are generally simply referred to as packets.

  Some other protocols also implement fragmentation of data into multiple packets. For example, TCP performs fragmentation of data into multiple segments. The segment is formally called a TCP protocol data unit (PDU: Protocol Data Unit). Nevertheless, the term packet is generally used when referring to PDUs and datagrams and when referring to Ethernet frames.

  Many protocols implement encapsulation of higher layer protocol packets. For example, IP implements encapsulation of a TCP packet by adding an IP header to the TCP packet to generate an IP packet. Therefore, the packet transmitted in the lower layer is considered to be composed of packets in the packet. In the normal case, a component operating according to one protocol only inspects or modifies information in a header and / or trailer generated by another component operating in accordance with the same protocol, typically another component in another node. do not do. That is, in general, components that operate according to one protocol do not inspect or modify portions of packets generated by other protocols.

  In another example of the abstraction provided by the layer protocol, several layers translate addresses. Some layers contain layer specific addressing schemes. For example, each end of the link is connected to the node via a real (eg electronic) interface or a virtual interface, eg an Ethernet interface. In layer 2 (data link layer), each interface has an address, for example, a media access control (MAC) address. On the other hand, in layer 3 using IP, each interface or at least each node has an IP address. Layer 3 converts the IP address into a MAC address.

  Typically, a router functions as a node that interconnects two or more separate networks, or two or more subnetworks (subnets) of a single network. As a result, “one network composed of a plurality of networks” (that is, one Internet) is formed. Thus, the router has at least two interfaces, each interface connecting the router to a different network, as illustrated in FIG. When a router receives a packet from one network via one interface, the router uses the information stored in its routing table to direct the packet to the other network via the other interface. The routing table includes the relationship between the network and the next hop. Their relevance informs the router that it can optimally reach a specific destination by sending a packet to the specific router that represents the next hop on the route to the final destination. For example, the first router 300 receives a packet from the first network 302 via its first interface 304, and the destination of the packet is designated as a node in the third network 306. If so, the first router 300 refers to its routing table and transfers the packet to the second network 310 via its second interface 308. Subsequently, the second network 310 transfers the packet to the third network 306. The next hop association can also be shown in the routing table as an output (egress) interface to the final destination.

  Large organizations, such as large enterprises, commercial data centers and telecommunications carriers, often use a set of hierarchical routers for transmitting internal traffic. For example, one or more gateway routers can interconnect each organization's network with one or more Internet Service Providers (ISPs). ISPs also use hierarchical routers to transmit traffic between their customer gateways to provide interconnection with other ISPs and with core routers in the Internet backbone.

  A router is considered a Layer 3 device because it is based on information in the Layer 3 IP packet, particularly the destination IP address, for its main forwarding decision. Conventional routers do not reference the actual data content (ie, encapsulated payload) that the packet carries. Instead, the router simply looks at the layer 3 address for making forwarding decisions and, optionally, other information in the header for hints such as quality of service (QoS) requests. When a packet is transferred, the conventional router does not maintain history information about the packet. However, even if the router is so configured, forwarding activity can be collected to generate statistical data.

  Accordingly, the IP network is regarded as a “stateless” network because it does not particularly retain this history information. For example, IP networks typically treat each request as an independent transaction that is not related to any previous request. Thus, the router can route the packet without regard to how the previous packet was processed. For example, IP networks typically do not store newly added communication partner status or session information. For example, if an intermediate transaction becomes unavailable to a part of the network, there is no need to reallocate resources, or otherwise the network state need not be fixed. Instead, the packet can be routed along other nodes in the network.

As described above, when a router receives a packet from one network via one interface, it uses its routing table to direct the packet to the other network. Table 1 lists information that can be generally seen from the basic IP routing table.

  The routing table can be filled manually, for example by a system administrator, or dynamically filled by a router. Routers use routing protocols to exchange information with other routers and thereby dynamically learn the surrounding network or Internet topology. For example, the router informs the network (s) of its presence. More specifically, the router notifies the network of the range of IP addresses to which the router can transfer packets. Neighboring routers use their information to update their routing tables and broadcast their ability to forward packets to the first router (s). This information is spread to more remote routers in the network as needed. Dynamic routing allows a router to react to changes in the network or the Internet, such as increased network congestion, the addition of new routers to the Internet, and router or link errors.

  Thus, the routing table provides a set of rules for routing packets to each destination. When a packet arrives, the router examines the contents of the packet, for example examines the destination address of the packet and finds the optimal rule in the routing table. The rule effectively informs the router which interface is used to forward the packet, and the IP address of the node to which the packet is forwarded on the path to the final destination IP address of the packet Also inform.

  In hop-by-hop routing, each routing table describes, for all reachable destinations, the address of the next node, that is, the next hop along the route to the destination. Assuming that the routing table is consistent, a simple algorithm for each router that relays the packet to each destination next hop is sufficient to send the packet anywhere in the network. The hop-by-hop scheme represents the basic characteristics of the IP internetwork layer and the OSI network layer.

  Thus, each router's routing table normally contains enough information to forward the packet to another router that is "relatively close" to the packet's destination, so that the packet is always There is no guarantee that it will be sent to the destination. In a sense, for the purpose of at least the majority of packets finally reaching their destination, the packets follow the sequence of routers and use the current rules at each router to By determining which router to follow, it finds its route to its destination.

  For example, if a router is congested or if a link fails, the rules may change between two consecutive hops of a packet or between two consecutive packets of a message. Let me mention that there is. Thus, two packets of a message may follow different paths and may instead arrive out of order. In other words, if the packet is transmitted from the source node or origin node, the network is stateless, so the packet is taken between the source node and the packet destination node in advance. There is generally no route routed. Instead, the route is typically determined dynamically as packets pass through various routers. This can be referred to as “natural routing”. That is, the route is dynamically determined when the packet passes through the Internet.

  Despite the fact that natural routing has worked well for many years, this natural routing has drawbacks. For example, it is difficult to collect metrics about a session because each packet of a session can propagate along different paths and can pass through different sets of routers. Security functions that can be applied to session packets must be distributed over a wide range, and there is also a risk that such security functions may not be applied to all packets. In addition, attacks on the session can be initiated from many locations.

  It should be noted that in a normal case, a packet transmitted from the destination node to the source node again may follow a different route from a packet transmitted from the source node to the destination node.

  In many situations, a client computer node (“client”) establishes a session with a server computer node (“server”), and the client and server exchange packets within that session. For example, a client running a browser can establish a session with a web server using conventional processes. The client can send one or more packets to request a web page, and the web server can respond with one or more packets containing the content of the web page. In some types of sessions, the round-trip exchange of packets can continue for multiple cycles. In some types of sessions, packets can be sent asynchronously between two nodes. Use well-known protocols such as Secure Sockets Layer Protocol (“SSL”) or Transport Layer Security Protocol (“TLS”) as described below This handshake can then be implemented to provide a secure session over the Internet.

  Session has its usual meaning. In other words, a session is a plurality of packets associated with each packet that are transmitted from one node to the other node according to a protocol. A session is considered to include a preceding packet (or first packet) that initiates the session and one or more subsequent packets of the session. A session has a clear start and a clear end. For example, a TCP session is initiated by a SYN packet. In some cases, the termination can be defined by one predetermined packet or series of packets. For example, a TCP session can be terminated by a FIN exchange or by an RST. In other cases, the termination can be defined by not performing communication between nodes for at least a predetermined length of time (timeout time). For example, a TCP session can be terminated after a predetermined timeout period. Some sessions contain only packets that are sent from one node to the other. Other sessions include response packets, as in the example of web client-server interaction. A session can include many cycles of round-trip or asynchronous communication according to the protocol, however, all packets in a session are sent between the same client-server pair of nodes. It is exchanged at. Here, the session is also referred to as a series of packets (packet series).

  A computer having a single IP address can provide various services such as a web service, an email service, and a file transfer protocol (FTP) service. Generally, each service is assigned a port number ranging from 0 to 65,535, which is unique on the computer. Therefore, the service is defined by a combination of the node IP address and the service port number. Note that this combination is unique within the network to which the computer is connected and is often unique within the Internet. Similarly, multiple clients can run on a single node. Therefore, since a client requesting a service is assigned a unique port number in the client node, a return packet from the service can be uniquely sent to the client that made the request.

  The term socket means a combination of an IP address and a port number. Thus, each service has a service socket that is network-specific and often Internet-specific, and a client socket that requests a service is assigned a client socket that may be network-specific or Internet-specific. It has been. In some cases, the terms source client and destination service are used to represent the client sending the packet to request the service and the service being requested, respectively.

Network Security and Control As stated above, hackers frequently attempt to gain unauthorized access to nodes in the network. In fact, some hackers have legitimate access to the network, and such hackers have a higher degree of autonomy with respect to the operation of network devices than if they had deliberate access. Such authenticated cases can have catastrophic consequences. FIG. 4 schematically illustrates a more specific type of network in which a hacker may attempt to gain access to a node in the local network. As shown, the network includes a client node / device 400 (simply referred to as “client 400”), eg, a client computer, which is connected to the local network via the Internet 404. Attempt to access one of a plurality of application servers (denoted collectively as “application server 402”). For illustration purposes, the local network is a local area network in a conventional data center. Of course, those skilled in the art will appreciate that the discussion of the data center and application server 402 is only an example, and that other topologies or other network devices may practice the illustrated embodiments of the present invention.

  Thus, the local network or, in this example, the data center has a plurality of application servers 402 as described above, which provide information to remote nodes / network devices, for example to clients 400. In this example, the data center has “N” application servers 402, which can represent dozens, hundreds or thousands of real and / or virtual servers. Among other things, the application server 402 can function as a web server for various retail stores, Internet services, social media sites, application service providers, and the like.

  The data center in this embodiment includes one or more edge nodes (in this example “edge routers”) for receiving and transferring data between a remote node (eg, client 400) and a node in the data center. 406 "). In other words, the edge router 406 manages data traffic between the local network and the distant devices in the Internet 404 or other close networks (eg forming a wide area network).

  To that end, the local network also includes a number of additional nodes / network devices, such as routers and switches (herein collectively referred to as “router 408”) for receiving and forwarding network traffic within the data center. Have. In the illustrated embodiment, the edge router 406 and other local network routers 408 transmit packets to the edge router 406 and application server 402 using a layer 3 protocol, eg, using the IP protocol. Or from the edge router 406 and the application server 402. The edge router 406 often has a direct physical link to the Internet 404 and its Internet service provider (ISP), but in some embodiments, the edge router 406 and the Internet 404 In the meantime, other devices may be physically located.

  FIG. 5 schematically illustrates an edge router 406 and some internal components of the edge router 406 for managing traffic to and from the network. As shown, the edge router 406 connects to other network devices, such as a router 408 in the data center to which it belongs and devices outside the local network to which it belongs, such as devices on the Internet 404 (eg, client 400). Interface 500 is provided. The interface 500 may include one or more physical or virtual interfaces for receiving or transmitting data packets, or for both receiving and transmitting.

  Correspondingly, the edge router 406 is represented by a local routing device (herein simply “router 502”) for routing data packets in the manner described above as defined by the various embodiments of the present invention. ). In particular, as will be described in more detail below with reference to FIG. 6, the router 502 controls the routing of data packets depending on the client information present in the client's digital certificate. In practice, as described below, various embodiments do not route client data packets unless the client 400 is properly authenticated. Therefore, the edge router 406 also has an authenticator 504 for verifying the identifier of the client 400. The illustrated embodiment may be implemented in any of a variety of ways known to those skilled in the art, such as hardware 502, software, firmware, or other means known to those skilled in the art, such as router 502, authenticator 504, and Interface (s) 500 may be implemented. Of course, their implementation should match their desired function. Their implementation will be described below with reference to FIG.

  Each of these edge router components can be interconnected in any of a variety of ways deemed appropriate to those skilled in the art. In FIG. 5, such a connection is shown schematically as a simple bus labeled 506. Of course, those skilled in the art will appreciate that the various embodiments of edge router 406 are not limited to similar bus designs.

  As mentioned above, a hacker may attempt to access an application server 402 in the data center. Access attempts by those hackers may be initiated from outside the local network or from within the network (eg, using guest access, eg, using a login ID and password). As described above, some hackers can legally or illegally acquire the privilege to establish a secure connection to the application server 402, thereby exploiting the application server 402. Without robust security measures, such hackers can cause serious problems. The illustrated embodiment mitigates such risks by imposing further restrictions on the authenticated client 400 attempting to access any of the plurality of application servers 402. To that end, FIG. 6 illustrates a process for providing such a security measure according to the illustrated embodiment of the present invention. This process is greatly simplified compared to the longer processes typically used to access server (s). Thus, this process can include other steps that are likely to be used by those skilled in the art, such as additional verification steps. Further, some steps can be performed in a different order than shown, or they can be performed simultaneously. Therefore, those skilled in the art can appropriately change this process.

  FIG. 6 illustrates various embodiments using the well-known transport layer security (“TLS”) protocol. In fact, the process of FIG. 6 works extensively with most of the TLS handshake cross-authentication processes used today. Of course, those skilled in the art will appreciate that the discussion of TLS is merely an example and is not intended to limit all embodiments of the present invention. Accordingly, the illustrated embodiment applies to other known security and encryption protocols that are configured to provide a secure connection over a network, eg, over the Internet 404.

  The process begins at step 600, where the edge router 406 receives a well-known “Hello” message from the client 400. Therefore, this message is accompanied by various data, for example, SSL version, supported encryption, session-specific data, and the like. The edge router 406 responds to the client 400 with its own unique “Hello” message and sends similar data to the client 400 (step 602). For example, in addition to the SSL version to client 400, supported ciphers, session specific data, etc., this Hello message also includes a server certificate and a mutual authentication request (which actually requests a client certificate). And includes an optional key exchange. At this point, authentication begins, thus completing the process that can be considered the first handshake process.

  Upon receiving the Hello message from the edge router 406, the client 400 transfers more data, eg, a client certificate, to the edge router 406 (step 604). As specified by TLS, this client certificate is preferably first transmitted in a “clear” format (ie, no encryption is performed). At this point in the process, the edge router 406 can determine that the client certificate was first authenticated / verified. If authenticated / verified, the authentication process continues. If not authenticated / verified, the process can be terminated by blocking all transmissions from the client 400.

  If verification occurs at this point, the authenticator 504 continues the handshake process in a conventional manner as defined by TLS. For example, after a client key exchange (pre-master secret for session, encrypted with server public key), client 400 then has its own client certificate verification (“CCV”: Client Certificate Verify). A message can be sent to prove to the edge router 406 that the client 400 has a private key corresponding to the public key in the client certificate. To that end, the client 400 generates a CCV message by hashing all TLS handshake messages (except for the CCV message) transmitted or received between the two devices between the client Hello message and the CCV message. .

  The edge router 406 verifies the signature of the CCV message using the public key to recalculate the hash for the same set of Hello messages. As is known to those skilled in the art, this is feasible because the private key is the only key that can generate a signature that can be verified using the corresponding public key.

  At this point in the process, the data packet from the client 400 does not pass through the edge router 406 and is therefore not destined for any other device or node in the local network. In this case, the edge router 406 preferably functions as a relay station for all packets from this client 400. For example, the edge router 406 can have a static TLS connection with the application server (s) 402. Thereby, no data packet can reach the application server 402 via the TLS connection until authentication and routing are performed as specified.

  However, in other embodiments, one or more limited packets can be forwarded from the client 400, eg, a Hello message. This of course depends on the flow of the authentication process. For example, upon receipt of a clear client certificate, the edge router 406 can first verify the client certificate (eg, verify the signature, among others), and send a Hello message to multiple application servers 402. Can be transmitted to one or more. In this embodiment, nonetheless, the edge router 406 is responsible for a significant amount of data from the client 400 until the final verification and authentication step is completed (eg, after the key exchange and client certificate verification process). Do not route packets.

  When the authentication process is complete, the final handshake process can be terminated. In particular, the process checks whether the authenticator 504 has authenticated the client 400 (step 606). If the authenticator 504 fails to authenticate the client 400, in this session, the edge router 406 sends a subsequent data packet via the interface 500 of this edge router 406 to any other in the data center. Block transmission to the device (step 608).

  In contrast, if authentication of the client 400 by the authenticator 504 is successful, the process proceeds to steps 610 and 612 and continues. In particular, in step 610, the edge router 406 routes client data packets using the information in the client certificate, and in step 612, the receiving node / application server 402 sets a policy derived from the client certificate. Apply appropriately.

  In particular, prior to a session request, an entity associated with the local network issues a client certificate to the client 400 along with a certificate authority. 7A and 7B schematically show an example of a client certificate configured according to the illustrated embodiment of the present invention. Certificates are mandatory standards, such as the widely used X.D. It has well-known information that is mostly the same as the information in a conventional certificate that conforms to the 509 standard. For example, a certificate includes, among other things, a version number, serial number, algorithm ID, issuer name, expiration date, and subject (subject) public key information.

  However, unlike other certificates used for those purposes, this client certificate also contains additional client information for routing client data packets within the local network. In particular, as shown in FIG. 7A, the client certificate has a subject line that identifies the details of the authorized person for the control of client 400 and client 400. Although FIG. 7A explicitly underlines subject lines, it should be noted that in many embodiments, this information is not required to be underlined. Instead, this line is underlined in FIG. 7A for emphasis only. Similarly in FIG. 7B, text (policy information, described below) is underlined for the purpose of emphasis only.

Among other things, the subject line in this example includes the country, state and office name of the client 400, as well as the department, name and email address of the particular user's job function. In this case, the user is John Smith and the e-mail address Smith @ 128technology. com . Mr. Smith is in the 128 Technology office in Massachusetts, USA, and belongs to the Engineering Department. Here, the subject information can be expressed as “identification information”, and this information identifies the client node 400 and a person who has been authenticated for use of the client node 400. Certainly, those skilled in the art can include more or less identification information or different information. For example, the identification information may additionally or alternatively include city information or municipal information, postal code information, telephone information, information on two or more people, two or more offices or departments, and the type of client device (eg, tablet , Personal computers, routers, etc.) or other types of information useful for a particular application.

  Step 610 preferably uses this identification information to route client packets within the local network. For example, a client 400 having this identification information profile can access only the application server 2 and therefore cannot access other application servers 402 in the local network. Accordingly, the router 502 of the edge router 406 forwards / routes the data packet from the client 400 to the application server 2 but does not forward / route to the other application server 402. As another example, the client 400 having this identification information profile can access only the application server 1 and the application server 2, or all applications except one application server in the local network. Server 402 can be accessed. As yet another example, the client 400 can access all application servers 402 on the network.

  Access granted to the client 400 is at the discretion. For example, a data center may separately have access agreements with hundreds, thousands, or millions of clients 400. A network administrator or other similar authority can program the edge router 406 to apply access routing to each particular client 400.

  In the illustrated embodiment, the client certificate is specific to the virtual or real device. Thus, in this example, a single user can have different access rights to different application servers 402, depending on the machine that the user uses to initiate a session. John Smith, for example, can have access to one application server 402 (eg, application server 1) in the local network when using his laptop computer, If used, it may have different access rights to another application server 402 (eg, application server 2) in the local network. However, in other embodiments, this is not required.

  The certificate may also have other types of client information related to other functionality or to enhance the routing functionality and / or verification functionality described above. In this case, the client certificate also has policy information that allows the client 400 to have a predetermined set of privileges when accessing the node (s) in the local network. In particular, in this example, in FIG. 7B, this policy information is represented as “X.509v3 Certificate Policies”, and a plurality of policies, namely Policy: 1.2.3.4.5 and Policy: 1.2.3.4.6 is mentioned.

  Logic within the local network (eg, application server 402) translates those enumerated policies into specific privileges for client 400. Those policies can be enforced / implemented in any way. In particular, in some embodiments, the policy is forwarded to the application server 402 along with the first data packet (after authentication). Accordingly, the logic in the receiving application server 402 is realized by reading out a policy related to the predetermined client 400.

  Those skilled in the art can use certificate policy lines for a wide variety of uses. For example, a first policy can specify that this client 400 can only access the technical section of the application server 1, while a second policy can specify that this client 400 is only for 128 Technology customers. It can be specified that a set of engineering departments can be accessed.

  As another example, the application server 402 may be a large grocery store chain, and the client 400 may be a product supplier that provides services to the grocery store chain. In such a case, the first policy can specify that the product supplier can only access the product section of that application server 402, while the second policy can specify that this particular client 400 Can only access data relating to planned product sales. Accordingly, the client 400 cannot access supplier data regarding other product suppliers of the grocery store, customer list, internal accounting department information of the grocery store chain, and the like. No further authority is expected or allowed. One skilled in the art can specify any of a wide variety of permissions / policies, and thus the permissions / policies listed above are merely examples of various embodiments. A network administrator or other authorized person in the local network can set, change and terminate policies as needed. In addition, a certificate can have fewer than two policies (eg, 0 or 1), or can have more than two policies if desired.

  In an alternative embodiment, authenticator 504 may implement an authentication process that is different from a typical authentication process that uses client information as part of the authentication process. Similarly, some embodiments may use both identification and policy information to allow the edge router 406 to specify where the client 400's data packet should be routed. For example, the policy information specifies that the application server 1 can receive packets from the client 400 between 8 am and 5 pm, and that the application server 2 can receive packets from the client 400 at other times. Can do.

  Further, some embodiments can route data to the application server 402 using only policy information. That is, the policy information can have unique routing information. For example, the first policy may precisely specify the application server 402 that this client 400 can access, for example, the application server 1.

  Those skilled in the art will recognize that this routing and policy application is done at the network level. Various embodiments further maintain higher level (eg, application level) security measures, eg, login identifier and password requests for access at some point in the process. However, in other embodiments, such a step is not required.

  The client certificate can be installed by any of a variety of conventional ways. For example, a client certificate can be installed on an iOS device via wireless communication using a configuration profile and the mobile device management (MDM) capability of the iOS device. Further, the client certificate can be installed on the iOS device by sending the PKCS12 version of the certificate as an email attachment. The client certificate can be manually installed on the Android device by sending the PKCS12 version of the client certificate as an email attachment or via an Android-specific mobile management product. Certainly, the drawings show their installation method, but are not intended to limit the various embodiments. One skilled in the art can use other methods to install the client certificate.

  The local network can log each time an attempt is made to access a node in the local network. Thus, the system can maintain stateful information. That is, the system can record all attempts, identifiers, and other related data. This system is particularly effective when used in conjunction with a system that uses state information in a stateless packet-based system, such as that described in the patent specification incorporated herein. It is. Thus, these systems can be integrated with the illustrated embodiment to more effectively maintain the local network and control network access.

  The illustrated embodiment also applies to devices / users accessing a local network via a guest interface (“guest user”). In particular, many guest interfaces implement the 802.1X protocol for connecting to a local network using a wired or wireless connection. Authentication can be compliant with any of such various protocols, eg, EAP-TLS or EAP-TTS. Guest users are provided with login ID and password information by widely used access techniques known to those skilled in the art. For example, the local network can provide a guest user with a login ID “Guest” and a password “NetworkX”. Thus, the guest user simply logs into the local network via a simple interface that requires a login ID and password. When security measures are not taken, guests can access resources on the network extensively.

  The illustrated embodiment controls this by providing network level security. In this case, as with the other embodiments described above, the local network or other entity may provide a specific guest certificate, for example as described above, and shown in FIGS. 7A and 7B. The guest certificate is issued to the guest user. As described above, this guest certificate has information specific to the guest user, and effectively restricts access to and use of the local network by the guest user. More specifically, in the illustrated embodiment, the guest certificate is one or more subject lines that identify the guest user's details, and the guest user to the node (s) in the local network. It also includes policy information that allows a predetermined set of privileges to be accessed. Thus, as described above for client 400, guest user access is limited by both of these two fields, device access and policy.

  The illustrated embodiment also associates the MAC address of the guest user's device (ie, the address used as the client device identifier) with the certificate. Thus, after the guest user logs into the local network, the edge router 406 or similar node maintains a record of the guest certificate and the MAC address of the guest user's device. In particular, in some embodiments, the edge router 406 can obtain the MAC address from the layer 2 header of the guest user's specific packet (s) (eg, the first packet).

  When a guest user logs off from the local network and then logs in again, the edge router 406 or similar node will send the MAC address and certificate of the device attempting access to the MAC address and certificate stored in its local memory. Can be compared with the book. If they match, the edge router 406 allows further access. However, if they do not match, the edge router 406 blocks further network access. In the latter case, the guest user can request acquisition of a new login ID and password, or registration of a new device using a new guest certificate or original guest certificate.

  Therefore, in this embodiment, in addition to controlling the use of and access to the local network by the guest user, the guest certificate accesses the local network and initiates a session with the local network. Support the certification of In other words, the guest certificate further ensures that the guest user is a legitimate guest. In fact, this and other embodiments apply to other types of users accessing the local network. Accordingly, the various embodiments are not limited to the above-described mode of access to the local network.

  Thus, the various embodiments improve detection techniques for certificate-based attacks and also mitigate the effects of those attacks (ideally stop such attacks). If implemented by the edge router 406, such attacks can be mitigated or stopped at an early point in the network (eg, before the packet reaches the application server 402). Accordingly, such an embodiment can check and enforce client / user certificates at the network level and can actively suppress unauthorized login attempts. In addition to protecting the application server 402, the various embodiments significantly reduce core network traffic while protecting the core network from attacks.

  The various embodiments of the invention may be implemented, at least in part, in any conventional computer program language. For example, some embodiments can be implemented in a procedural programming language (eg, “C”) or an object-oriented programming language (eg, “C ++”). Other embodiments of the invention as pre-configured stand-alone hardware elements and / or pre-programmed hardware elements (eg, application specific integrated circuits, FPGAs and digital signal processors), or It can be realized as other related components.

  In one alternative embodiment, the disclosed apparatus and method (see, for example, the various flowcharts above) can be implemented as a computer program product for use with a computer system. Such embodiments include a series of computer instructions stored on a tangible non-transitory medium, such as a computer readable medium (eg, a diskette, CD-ROM, ROM, or fixed disk). be able to. The series of computer instructions may implement all or part of the functionality described above with respect to the system herein.

  Those skilled in the art will appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Further, such instructions can be stored in any memory device, eg, a semiconductor device, magnetic device, optical device or other memory device, and can be used using any communication technology, eg, optical transmission technology. It can be transmitted using infrared transmission technology, microwave transmission technology or other transmission technology.

  In addition, such computer program products can be distributed as removable media with printed or electronic documents (eg, commercially available software) and preloaded into a computer system (eg, on a system ROM or fixed disk). Or can be distributed from a server or bulletin board via a network (eg, the Internet or the World Wide Web). In practice, some embodiments may be implemented as a SaaS (Software as a Service) model or a cloud computing model. Of course, some embodiments of the present invention may be implemented as a combination of software (eg, a computer program product) and hardware. Still other embodiments of the invention are implemented entirely as hardware or entirely as software.

  While various embodiments of the invention have been described above, those skilled in the art can make various modifications that achieve some of the advantages of the invention without departing from the true spirit of the invention. I understand.

Claims (39)

In a method for routing data over a network,
The method
Receiving a session request from a client node accessing at least one node in a local network having a plurality of nodes;
Receiving from the client node a client certificate having client information specifying at least one node that receives packets from the client node;
Performing an authentication process using the client certificate;
Retrieving the client information from the client certificate;
If the client node is authenticated by the authentication process, the data packet received from the client node is sent to at least one node in the local network as specified by the client information in the client certificate. Routing, and
A method characterized by comprising: Further comprising rejecting the client node if the client node is not authenticated by the authentication process;
The method of claim 1. The rejection includes blocking access of the client node packet to other nodes in the local network.
The method of claim 2. The client information includes identification information for identifying the client node.
The method of claim 1. Data packet routing
Using the client information to determine an identifier of the at least one node in the local network that receives the data packet from the client node;
Routing data packets from the client node to the identified at least one node;
Including,
The method of claim 1. If authenticated, routing allows the client node to access the at least one node;
The client information includes policy information that grants a set of privileges to the client node when accessing the at least one node in the local network.
The method of claim 5. The client information is
a) identification information for identifying the client node, or
b) policy information that grants a set of privileges to the client node when accessing the at least one node in the local network; or
c) both (a) and (b),
Including,
The method of claim 1. Data packet routing includes routing data packets as specified by one or both of the identification information and the policy information.
The method of claim 7. The local network includes an edge router that performs at least one of receiving a session request, receiving a client certificate, searching, and routing.
The method of claim 1. The at least one node has an application server;
The local network includes a local area network.
The method of claim 1. A receiving node in the local network receives the session request;
The method further comprises maintaining a static connection between the receiving node and the at least one node in the local network;
Routing includes routing of data packets from the client along the static connection.
The method of claim 1. No handshake process is performed between the client node and the at least one node in the local network during the session;
The method of claim 11. Allowing an initial handshake process between the client node and the at least one node before receiving the certificate;
Authorizing completion of a final handshake process between the client node and at least one node if the client node is authenticated by the authentication process;
In addition,
The method of claim 1. Execution of the authentication process includes receiving a login ID and password for a guest user and confirming that the login ID and password are valid for access within the local network.
The method of claim 1. Determining a client device identifier that identifies the client node device;
Performing the authentication process using the client device identifier and the client certificate;
In addition,
The method according to claim 14. The client device identifier includes a MAC address;
The method of claim 15. In a network routing device that routes data received over the network,
The network device is
a) a session request from a client node accessing at least one node in a local network having a plurality of nodes; and b) client information specifying at least one node receiving a packet from the client node. An interface for receiving a client certificate from the client node;
An authenticator connected to the interface to work properly and configured to retrieve the client certificate and perform an authentication process using the client certificate;
A router connected to the authenticator to function properly and configured to determine from the authenticator whether the client node has been authenticated by the authentication process;
Contains
The router further includes, when the client node is authenticated, the data packet received from the client node, as specified by the client information in the client certificate, at least one in the local network. Configured to route to the node,
Network routing device. The client information includes identification information for identifying the client node.
The network routing device of claim 17. The router is configured to use the client information to determine an identifier of the at least one node in the local network that receives the data packet from the client node;
The router is further configured to route client data packets from the client node to the identified at least one node;
The network routing device of claim 17. The router is configured to authorize access to the at least one node by the client node if authenticated;
The client information includes policy information that grants a set of privileges to the client node when accessing the at least one node in the local network.
The network routing device according to claim 19. The client information is
a) identification information for identifying the client node, or
b) policy information that grants a set of privileges to the client node when accessing the at least one node in the local network; or
c) both (a) and (b),
Including,
The network routing device of claim 17. The router is configured to route data packets as specified by one or both of identification information and policy information;
The network routing device of claim 21. The router is configured as an edge router for the local network;
The network device according to claim 17. In a computer program product used in a computer system for routing data over a network,
The computer program product comprises a tangible non-transitory computer usable medium and computer readable program code on the medium,
The computer readable program code is:
Program code for receiving a session request from a client node accessing at least one node in a local network having a plurality of nodes;
Program code for receiving from the client node a client certificate having client information specifying at least one node that receives packets from the client node;
Program code for performing an authentication process using the client certificate;
Program code for retrieving the client information from the client certificate;
If the client node is authenticated by the authentication process, the data packet received from the client node is sent to at least one node in the local network as specified by the client information in the client certificate. Program code for routing,
Including computer program products. If the authentication process fails to authenticate the client node, it further includes program code for rejecting the client node.
25. A computer program product according to claim 24. The program code for rejecting includes program code for blocking access of the client node packet to other nodes in the local network.
26. A computer program product according to claim 25. The client information includes identification information for identifying the client node.
25. A computer program product according to claim 24. Program code for routing the data packet is:
Program code for using the client information to determine an identifier of the at least one node in the local network that receives the data packet from the client node;
Program code for routing data packets from the client node to the identified at least one node;
Including,
25. A computer program product according to claim 24. If authenticated by the program code for routing, the client node is permitted to access the at least one node;
The client information includes policy information that grants a set of privileges to the client node when accessing the at least one node in the local network.
29. A computer program product according to claim 28. The client information is
a) identification information for identifying the client node, or
b) policy information that grants a set of privileges to the client node when accessing the at least one node in the local network; or
c) both (a) and (b),
Including,
25. A computer program product according to claim 24. The program code for routing the data packet includes a program code for routing the data packet as specified by one or both of identification information and the policy information.
The computer program product of claim 30. The local network has at least one of a program code for receiving the session request, a program code for receiving the client certificate, a program code for searching, and a program code for routing. Including edge routers to run,
25. A computer program product according to claim 24. The at least one node has an application server;
The local network includes a local area network.
25. A computer program product according to claim 24. A receiving node in the local network receives the session request;
The computer program product further includes program code for maintaining a static connection between the receiving node and the at least one node in the local network;
The program code for routing includes program code for routing data packets from the client along the static connection.
25. A computer program product according to claim 24. No handshake process is performed between the client node and the at least one node in the local network during the session;
35. A computer program product according to claim 34. Program code for authorizing an initial handshake process between the client node and the at least one node before receiving the certificate;
Program code for authorizing completion of a final handshake process between the client node and at least one node if the client node is authenticated by the authentication process;
Further including
25. A computer program product according to claim 24. In a method for routing data over a network,
The method
Receiving a session request from a client node accessing at least one node in a local network having a plurality of nodes;
Receiving from the client node a client certificate having client information specifying at least one node that receives packets from the client node;
Retrieving the client information from the client certificate;
Facilitating at least restrictive access to the at least one node based on the client information in the client certificate;
A method characterized by comprising: The client information includes policy information.
38. The method of claim 37. The at least one node has a set of associated access privileges;
Facilitating at least restrictive access includes granting the client node at least one of the associated set of access privileges;
40. The method of claim 38.

Images