Abstract:
A method for communication includes predefining two or more client profiles applicable to clients of a communication network. Virtual Private Network (VPN) connections are initiated between at least two of the clients and the network. At least two of the clients are matched with respective profiles selected from the two or more predefined client profiles. Priorities are assigned to packets exchanged between the at least two of the clients and the network responsively to the profiles. The VPN connections are set up for the at least two of the clients responsively to the priorities.

Description:
FIELD OF THE INVENTION 
     The present invention relates generally to computer networks, and particularly to methods and systems for prioritizing the setting up of Virtual Private Network (VPN) connections over communication networks. 
     BACKGROUND OF THE INVENTION 
     Many organizations use Virtual Private Networks (VPNs) to connect users and remote sites securely to their corporate network. VPNs over Internet Protocol (IP) networks often use the IP security (IPsec) protocol suite, which provides a set of cryptographically-based security services. The IPsec architecture is described by Kent and Atkinson in “Security Architecture for the Internet Protocol,” published as Request for Comments 2401 by the Internet Engineering Task Force (IETF RFC 2401), November 1998, which is incorporated herein by reference. 
     Internet key exchange (IKE) is a sub-protocol of IPsec that authenticates each peer in an IPsec transaction, negotiates security policy and handles the exchange of encryption keys. IKE is described by Harkins and Carrel in “The Internet Key Exchange,” IETF RFC 2409, November 1998, which is incorporated herein by reference. 
     The Internet Security Association and Key Management Protocol (ISAKMP) is a protocol that is part of IKE. ISAKMP defines procedures and packet formats for establishing, negotiating, modifying and deleting security associations (SA) between peers. ISAKMP is defined by Maughan, et al., in “Internet Security Association and Key Management Protocol (ISAKMP),” IETF RFC 2408, November 1998, which is incorporated herein by reference. 
     The present invention will be more fully understood from the following detailed description of the embodiments thereof, taken together with the drawings in which: 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram that schematically illustrates a computer network, in accordance with an embodiment of the present invention; and 
         FIG. 2  is a flow chart that schematically illustrates a method for prioritizing VPN tunnel setup requests, in accordance with an embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS 
     System Description 
       FIG. 1  is a block diagram that schematically illustrates a computer network  20 , in accordance with an embodiment of the present invention. Network  20  comprises multiple remote clients  24  and remote sites  28  that connect to a corporate network  32  via a wide-area network (WAN)  36 , such as the Internet. Corporate network  32  typically belongs to an organization having employees and/or customers that need to remotely connect to the organizational network. Remote clients  24  may comprise, for example, employees working from home and traveling users connecting to the network from hotel rooms or via wireless hotspots. Remote sites  28  may comprise, for example, branch offices located away from the corporate headquarters and customers or suppliers that are granted access to certain services of the corporate network. In some embodiments typical of remote branch offices, remote site  28  comprises a number of personal computers or work-stations  37  connected by a local area network (LAN)  38 . LAN  38  is connected to WAN  36  using a router  39 . (In the description that follows, remote clients and remote sites are collectively referred to as “clients” for the sake of simplicity.) 
     In many applications it is desirable to maintain a high level of information security when communicating over WAN  36 . For this purpose, clients  24  and sites  28  are connected to network  32  using Virtual Private Network (VPN) connections, also referred to as VPN tunnels. Each client establishes a secure VPN tunnel to corporate network  32  via a VPN aggregator  40 . In particular, aggregator  40  prioritizes the setting up of VPN tunnels for different client types based on predefined client profiles, as will be explained in detail below. In some embodiments, aggregator  40  may prioritize and set up VPN tunnels for any or all of the clients of network  32 . 
     Some exemplary VPN aggregators that can use the prioritization methods described herein are the VPN 3000 series concentrators produced by Cisco Systems, Inc. (San Jose, Calif.). 
     Each VPN tunnel generally uses a secure communication protocol between the client and the VPN aggregator. The protocol typically uses mutually-agreed encryption keys to encrypt and decrypt the information being transferred. In some embodiments, networks  32  and comprise Internet Protocol (IP) networks that communicate by exchanging IP packets. In these embodiments, the exchange of packets within and between these networks is performed in accordance with the IPsec and IKE protocols, as defined and described in the IETF RFCs cited above. 
     The network configuration shown in  FIG. 1  is an exemplary configuration chosen purely for the sake of conceptual clarity. In general, network  20  may comprise any number of remote clients and/or remote sites. Remote clients and sites may be connected to WAN  36  using any suitable wired or wireless links. Aggregator  40  may comprise any network element, which may serve as the gateway connecting corporate network  32  to WAN  36 , or may be part of any other suitable configuration that connects the two networks. Corporate network  32  may comprise a private network or be implemented as part of a shared public network whose services are provided by a service provider. 
     Although the embodiments described herein mainly relate to a “responder mode” in which the clients initiate the setting up of VPN tunnels with network  32 , the methods and systems described herein can be used,  mutatis mutandis , in an “initiator mode” in which aggregator  40  initiates the setting up of the VPN tunnels. 
     Aggregator  40  comprises an aggregation processor  44 , which performs the various functions associated with setting up and managing the VPN tunnels, and a network interface  48 , for communicating with WAN  36  and with the different components of corporate network  32 . Typically, processor  44  of aggregator  40  comprises a general-purpose computer, which is programmed in software to carry out the functions described herein. The software may be downloaded to the computer in electronic form, over a network, for example, or it may alternatively be supplied to the computer on tangible media, such as CD-ROM. Further alternatively, processor  44  may be implemented using a combination of hardware and software elements. The processor may be a standalone unit, or it may alternatively be integrated with other computing platforms of corporate network  32 . 
     Typically, a newly-joining client sends an IKE request packet to the VPN aggregator, requesting to set up a VPN connection (tunnel) to network  32 . The VPN aggregator receives the request packet and performs a tunnel setup process that authenticates the client and exchanges encryption keys. In many cases, the IKE process of setting up a VPN tunnel for a newly-joining client is a long and computation-intensive process that consumes a significant amount of time and computation resources in aggregator  40 . The length and complexity of this process are partly due to the algebraic calculations associated with generating the encryption keys. In some cases, aggregator  40  may need to communicate with other nodes in network  32  in order to authenticate a particular client, which further lengthens the tunnel setup process. 
     In some applications, aggregator  40  supports many thousands of clients simultaneously. In peak periods (such as at the beginning of a working day), several hundred clients may request to set up VPN tunnels every second. Due to the finite resources of the aggregator, some of these clients may experience a noticeable delay in setting up their VPN tunnels. An extreme scenario occurs when parts of the network, or aggregator  40  itself, recover from a communication failure that affects a large number of clients. When the network recovers, thousands of clients may request to set up VPN tunnels simultaneously. In such a scenario, some of these clients may suffer significant delays of up to several minutes in establishing their VPN connections. Clearly, such delays may be considered a prohibitive and intolerable quality of service (QoS) flaw by some clients and applications. 
     Some VPN applications use a Call Admission Control (CAC) mechanism, which limits the rate of tunnel setup request packets being processed in order to protect the resources of the aggregator. Typically, when the aggregator resource utilization exceeds a predetermined threshold, the CAC process prevents subsequent request packets from being processed. For example, in some embodiments the CAC process measures the aggregator processor utilization (i.e., the percentage of CPU resources used). If the processor utilization crosses a predetermined threshold, the CAC process rejects subsequent request packets. Because of the computational complexity of the tunnel setup process, the CAC process often gives higher priority to requests whose processing has already begun and may reject new requests. 
     In view of the long setup delays that may be experienced by clients, it is sometimes desirable to assign priorities to the setup request packets based on a classification of the clients. For example, in some networks it is desirable to give remote sites (e.g., branch offices) priority over individual remote clients. As another example, some remote clients may be classified as senior employees or as premium customers that are offered higher service quality. In other cases, it is desirable to give higher priority to VPN tunnels that use voice services or to tunnels used for network control. Request packets from clients having higher priority should be handled first by the aggregator, thereby shortening the connection delay for these clients. 
     Existing QoS mechanisms, such as the Modular QoS Command line interface (MQC) provided by Cisco Systems, Inc. (San Jose, Calif.), are generally unsuitable for prioritizing IKE request packets. Since the majority of IKE-related information is encrypted, such QoS mechanisms are generally unable to process and prioritize IKE packets. 
     Prioritization Method Description 
     In order to provide a faster connection time and an overall better QoS to selected client types, embodiments of the present invention provide methods and systems for prioritizing the setting-up of VPN tunnels based on client profiles. 
       FIG. 2  is a flow chart that schematically illustrates a method for prioritizing VPN tunnel setup requests, carried out by VPN aggregator  40  in accordance with an embodiment of the present invention. The method begins with an operator, such as a system administrator, defining a configuration of two or more client profiles, at a profile definition step  60 . Each client profile defines the client&#39;s association with certain predetermined client categories. A client category may comprise, for example, branch offices or other remote sites. Other client categories may comprise, for example, senior employees or premium customers. In general, the configuration of client profiles is arranged so that every client is associated with no more than a single profile. 
     As part of the profile definition, each client category is assigned a priority level. Typically, the priority level is represented as a number selected from a predetermined range. 
     In some VPN applications, the VPN aggregator maintains a set of ISAKMP profiles as part of the ISAKMP process. The ISAKMP profiles are used, for example, for identity matching, certificate filtering, authentication, authorization and virtual routing and forwarding (VRF). In some embodiments of the present invention, the ISAKMP profiles are adapted to serve as client profiles for prioritizing the VPN tunnel setup requests. For this purpose, an additional “priority” command is added to the ISAKMP profile. The following code shows an exemplary configuration comprising three adapted ISAKMP profiles: 
     crypto isakmp profile cisco
         vrf cisco   match identity group cisco-vpncluster   match identity user JohnChambers
           priority 1   
           match identity group cisco-engineers
           priority 2   
           match identity group cisco-sales
           priority 3   
           match certificate group cisco-ca   keying cisco-keyring   client authentication list cisco-client   isakmp authorization list global-aaa   priority 1       

     crypto isakmp profile company-A
         vrf cmp-A   match identity group cmp-A-vpncluster   match certificate group cmp-A-ca   keying cmp-A-keyring   client authentication list cmp-A-client   isakmp authorization list global-aaa   priority 2       

     crypto isakmp profile company-B
         vrf cmp-B   match identity group cmp-B-vpncluster   match certificate group cmp-B-ca   keying cmp-B-keyring   client authentication list amp-B-client   isakmp authorization list global-aaa   priority 2       

     Each ISAKMP profile comprises one or more “match identity” commands, identifying client categories such as client groups or individual clients. In some embodiments, when a “priority” command is added below a certain “match identity” command, the aggregator assigns the priority level specified in this command to this category. When a single “priority” command is added to the entire ISAKMP profile, this priority level applies to all “match identity” commands in this profile. (See, for example, the “company-A” and “company-B” profiles above.) 
     Having defined the client profiles, the profiles are provided to aggregator  40 . In some embodiments, the configuration of client profiles can be modified and updated whenever necessary during operation. 
     Aggregator  40  receives IKE VPN tunnel setup request packets (referred to as request packets for brevity) from clients of corporate network  32 , at a request reception step  62 . According to the IKE protocol, each request packet comprises an identification (ID) payload, which identifies the client sending the packet. 
     Aggregator  40  matches each VPN request packet with one of the client profiles, at a matching step  64 . In some embodiments, the aggregator extracts the ID payload from the request packet and attempts to match it against the different “match identity” commands in the ISAKMP profiles. If a matching “match identity” command is found, the aggregator reads the priority level assigned to this category from the client profile and assigns the priority level to the request packet. In some embodiments, if a match is not found, the request packet is assigned a default priority level, such as the lowest priority level. Alternatively, the request packet may be dropped. 
     Aggregator  40  prioritizes the request packets, at a prioritization step  66 . In some embodiments, aggregator uses the priority levels assigned to each request packet at step  64  above to prioritize the handling of the packets. Typically, request packets having the same priority level are handled on a “first come, first served” basis, although any other criterion can be used for this purpose. 
     In some embodiments, aggregator  40  operates a prioritized Call Admission Control (CAC) mechanism responsively to the assigned priorities, at a CAC operation step  68 . For example, the CAC mechanism may operate several queues, each queue associated with a particular priority level. After assigning priorities to the request packets, the aggregator adds each request packet to the queue associated with the priority of this packet. The queues are then served, typically giving more weight to queues associated with higher priority levels. Any suitable scheduling method known in the art, such as Modified Deficit Round Robin (MDRR), can be used for this purpose. As noted above, the CAC mechanism is used to protect the aggregator resources, typically by rejecting pending request packets when the aggregator utilization exceeds a predetermined threshold. However, when using the CAC mechanism described above, high priority requests are served first and are unlikely to be rejected. 
     Aggregator  40  sets up VPN tunnels according to the prioritized order of the request packets, at a tunnel setup step  70 . The method then returns to request reception step  62  above for receiving subsequent request packets. 
     In some embodiments, aggregator  40  may assign priorities to clients responsively to measured traffic characteristics of the clients. For example, the aggregator may measure the volume of traffic (e.g. the average packet rate) originating from each client and assign a higher priority to high traffic clients. As another example, the aggregator may identify service types used by clients, and give a higher priority to clients who frequently use a certain service type (e.g. voice). Any other suitable traffic characteristic or combination of characteristics can be used for this purpose. The measurement of the traffic characteristics and the assignment of priorities based on these characteristics may be performed during a learning period and/or during normal operation of the network. The process may be fully-automated or may involve a human operator, for example for verifying the automated assignments, for reviewing measured characteristics or for manually assigning priorities to automatically measured traffic characteristics. 
     Although the embodiments described herein relate mainly to prioritizing IKE VPN tunnel setup requests, the principles of the present invention can also be used in other tunnel-based protocols that use aggregators, such as PPP, L2TP, SSH and SSL. 
     It will thus be appreciated that the embodiments described above are cited by way of example, and that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and sub-combinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art.