WO2004066579A1

WO2004066579A1 - Stateless server cluster for internet traffic

Info

Publication number: WO2004066579A1
Application number: PCT/FI2003/000956
Authority: WO
Inventors: Ilkka PIETIKÄINEN
Original assignee: Netseal Mobility Technologies - Nmt Oy
Priority date: 2003-01-17
Filing date: 2003-12-15
Publication date: 2004-08-05
Also published as: FI20030073A; FI20030073A0; FI117263B; AU2003288291A1; EP1620989A1

Abstract

The method is generally based on the idea that a sender of a communication packet places a piece of information in a certain header field of the communi-cation packet. On the basis of the said piece of information, the master of the server cluster receiving the communication packet can then determine which slave should handle the said packet. The same idea can be exploited during a security association (SA) negotiation. The SA negotiation may be per-formed using Internet Security Association and Key Management Protocol (ISAKMP) packets. When the SA is negotiated Internet Protocol security (IP-sec) packets are preferably used as communication packets.

Description

Stateless server cluster for Internet traffic

Field of the invention

The present invention generally relates to efficiency and security aspects when a server cluster handles communication packets.

Background of the invention

The Internet Protocol security (IPsec) is a security feature providing a robust authentication and encryption of IP packets. When using IPsec, an association between the sender and the receiver of the IP packets is termed "a security association" (SA). The terms "node" and "entity" refer to a terminal, a server, a router, or some other type of equipment that participates in an SA. An SA is created between the end nodes of a connection. There may be one SA per connection, but usually both communication directions have their own SA. It is also possible that different types of traffic for the same connection have been secured with their own SA.

In IPsec traffic, IP packets contain an Authentication Header (AH) or an Encapsulated Security Payload (ESP). These packets are termed IPsec packets.

FIG. 1A shows the authentication header (AH) 101. Two of its fields are discussed here, because they relate closely to the invention. Information about the rest of the AH fields can be found in prior art documents. The Security Parameters Index (SPI) is a field 102 for storing an SPI number that identifies a security association. The Sequence Number Field is a field 103 for storing a sequence number. The sequence number is incremented after each packet is sent.

FIG. 1 B shows a part of the encapsulated security payload (ESP) 104. Also the ESP header includes the Security Parameters Index (SPI) field 105 for storing an SPI number identifying a security association. Correspondingly, the sequence number field 106 is for storing a sequence number.

In IPsec traffic, an IP packet can be encapsulated using the AH or the ESP. The encapsulation of an IP packet can be performed in the tunnel mode or the transport mode. Both modes are described in prior art documents.

The Internet Key Exchange (IKE) protocol is the protocol standard for the key management. IPsec can be configured without IKE, but IKE en- hances the IPsec by providing certain additional features. The operation of IKE is based on both: the key determination protocol termed "Oakley" and the Internet Security Association and Key Management Protocol (ISAKMP). ISAKMP defines formats for the packet payload, the mechanics of implementing a key exchange protocol, and the negotiation of an SA. IKE may automatically negotiate security associations (SAs) and thus enable IPsec traffic without manual configuration.

FIG. 2 shows a part of the ISAKMP header 201. In addition to the ISAKMP header, an ISAKMP packet carries a variable number of payloads. The Initiator Cookie field 202 of the ISAKMP header includes an identifier of an entity that has initiated the establishment, notification, or deletion of an SA. The Responder Cookie field 203 includes an identifier of another entity that responds to the establishment, notification, or deletion of the SA.

A server cluster is generally composed of a set of servers. The term "clustering" refers to the manner, whereby services are shared among the servers. There are basically two types of services, application services and network services. When clustering application services, the objective is to increase the capacity of the application services. Typically, the capacity requirements of a sen/ice are much higher in a server running the service than in another server handling the traffic of the service. For example, a server running a WWW search service may require high processing capacity. When clustering network services, basically all the processing capacity is needed for processing the traffic of application services. Therefore, a server or server cluster should handle the traffic as efficient as possible.

Many clustering solutions for network services are based on broadcasting communication packets at layer two of the OSI model to all members of the server cluster (OSI is an acronym from the words "Open Systems Interconnection"). All the packets are distributed to all the members, and each member determines through the use of some prior art method whether it should process a broadcasted packet or not. This solution operates relatively well in most cases, but it may suffer from the following drawbacks.

First, each member must be able to receive all the packets sent to the server cluster. Thus, each member may need an expensive high-capacity link for receiving packets. Secondly, each member must discard packets intended for other members. When the volume of the received packets increases, discarding the packets requires more and more capacity.

Instead of broadcasting or multicasting all packets to all the server cluster members, a server cluster can be composed of a master server and slave servers so that the server cluster has one IP address and the said IP address is mapped to the master server. In this solution the master receives all the packets and distributes them to the slaves via a network that connects the master and the slaves. Of course, this solution suffers its own drawbacks.

The first drawback is that many prior art server clusters composed of a master and slaves contain a lot of shared information which must be continuously updated. The said information includes security associations which must be evenly shared among the slaves. This sharing may cause a lot of internal message traffic in the server cluster.

The second drawback is that the prior art server cluster may fail to repel certain types of hacker attacks, such as replay attacks.

The applicant's former patent application FI20022102 describes a server cluster that can repel replay attacks. The said server cluster has its own benefits and drawbacks. One benefit is that the failure of one slave does not usually cut off a connection, because the connection is usually handled by at least two slaves of the said server cluster. Correspondingly, the drawbacks in comparison with the server cluster described in this patent application are as follows: 1) the space requirement of the slaves is higher and 2) the synchronization of the slaves' operation requires more work.

Summary of the invention

The invention is generally based on the idea that a sender of a communication packet places a piece of information in a certain header field of the communication packet. On the basis of the said piece of information, the master of the server cluster receiving the said communication packet can determine which slave is to handle the packet.

The server cluster may receive negotiation packets, such as ISAKMP packets, and security packets, such as IPsec packets. The master of the server cluster obtains a negotiation packet with an initiator field and a responder field. The initiator field contains a value identifying the negotiation initiator. If the responder field of the negotiation packet contains a dummy value, the master selects a slave server for a security association.

For example, the master may select the slave having the lowest load. When a slave is selected, a security association can be negotiated in two different ways.

The first way is that the master negotiates the security association on behalf of the selected slave. Then the master selects a handler value from the number space which is addressed to the selected slave. For example, the handler value may be a certain Security Parameters Index (SPI) value between a certain lower limit and a certain upper limit.

The second way is that the master transmits the negotiation packet to the selected slave, which selects the responder value itself and then negotiates the security association.

Both ways involve the placement of the responder value in a negotiation packet sent to the negotiation initiator. When the master receives the next negotiation packet from the negotiation initiator, said packet contains the responder value. On the basis of the responder value, the master determines to which slave the packet should be transmitted.

It is also possible that a user creates a security association.

When a security association (SA) is negotiated between an entity and the server cluster, or the SA is created by a user during an SA setup, the said entity sends security packets belonging to the SA to the server cluster. If the security packets are IPsec packets, they may contain, for example, an SPI value. In any case, the security packets contain a handler value. The handler value is selected from the number space addressed to the slave handling the security packets. On the basis of the handler value, the master determines to which slave the security packets should be transmitted.

Brief description of the drawings

The invention is described more closely with reference to the accompanying drawings, in which

Figure 1A shows the authentication header (AH),

Figure 1B shows a part of the encapsulated security payload (ESP),

Figure 2 shows a part of the ISAKMP header,

Figure 3 shows the main steps in the method, Figure 4 shows the steps of the method for negotiating a security association, Figure 5 shows an example of a server cluster.

Detailed description of the invention

The invention comprises a method for handling security packets and a server cluster using that method.

Each slave server has two number spaces which are termed a "handler number space" and a "responder number space" respectively. A handler value is selected from the handler number space, and a responder value is selected from the responder number space. It is possible that the said number spaces are the same number space, i.e. that they include exactly the same numbers.

In any case, the number spaces of different slaves are separated, i.e. they do not include the same numbers. Each number space may contain numbers from a certain minimum limit to a certain maximum limit. For example, the number space addressed to a first slave could contain the numbers from 0 to 32767 and the number space addressed to a second slave could contain the numbers from 32768 to 65535.

FIG. 3 shows the main steps of the method intended for handling security packets in a server cluster composed of a master server and at least one slave server. The security packets may be IPsec packets. The first step is receiving 301 at the master server a security packet which belongs to a security association (SA) between an entity and the server cluster. The SA may be created by a user. Alternatively, the entity and the server cluster have negotiated the SA using negotiation packets. The security packet received includes a handler value originating from the server cluster. The handler value is selected during the SA negotiations. Alternatively, it is selected when a user creates the SA. The second step is determining 302 the slave server with the handler number space that the said handler value belongs to and then transmitting 303 the security packet to the said slave server.

Generally, the number spaces of slaves are determined by using an appropriate function. The function may be very simple. For example, it may divide a given number space into two number spaces so that the number space of one slave contains odd numbers and the number space of an- other slave contains even numbers. Any bit string can be considered as an integral number that can be used as an input of the function.

It should be noted that characters and character strings/bit strings can be represented as hexadecimal numbers. Therefore, a character string represent as a hexadecimal number may belong to a certain number space, which can be mapped to a certain slave server. Therefore, the character string is also a piece of information that can be used as a handler value.

Basically, there are two alternative ways to negotiate an SA between an entity and a server cluster. The first way is that the master negotiates the SA on behalf of a slave and the second way is that a slave server negotiates the SA. Both ways are explained in the following figure.

FIG. 4 shows the steps for negotiating an SA. The negotiation is performed using negotiation packets, such as ISAKMP packets. The first step is receiving 401 a negotiation packet sent by the entity. The second step is comparing 402 a predefined dummy value to the responder value included in the negotiation packet. If the responder value is the dummy value, the next step is selecting 403 a slave server of the server cluster. For example, the selection may be based on the load amounts so that the slave having the lowest load is selected. If required, the master may also operate as a slave. Thus, the master may select itself as a slave server and handle a part of the load. The selected slave, which may be the master, will handle security packets related to the SA. The next step is selecting 404 a responder value which differs from the dummy value and which belongs to the responder number space addressed to the selected slave. The responder value is preferably the same value used as a handler value in communication packets when the entity sends the said packets to the selected slave. Step 404 is preferably performed by the selected slave. Then the said slave obtains the first negotiation packet from the master, and the said slave negotiates the SA. However, the master may also select the responder value on behalf of the slave, in which case the master negotiates the SA. The next step is sending 405 a first "response" negotiation packet with the responder value to the entity in response to the negotiation packet received. If the selected slave negotiates the SA, the first response negotiation packet is sent by it. Otherwise, the master negotiates the SA and sends the said negotiation packet. If the responder value differs from the dummy value, the step is determining 406 a slave server with the responder number space to which the responder value belongs. If the selected slave negotiates the SA, the master transmits the negotiation packet to it. The final step is sending 405 the first response negotiation packet with the responder value to the entity.

As mentioned above, a handler value and a responder value may be the same value. In that case, there is no need for a mapping or for a transformation between the handler value and the responder value. In other words, an entity can use the responder value received from a server cluster as a handler value when it sends security packets to the server cluster. Then the responder value and the handler value point to the same slave server in the server cluster. In addition, if the handler number space and the responder number space are the same number space, the same logic can be used to determine 1) which slave is to handle a negotiation packet and 2) which slave is to handle a security packet. For example, the Security Parameters Index (SPI) value can be used as a responder value. The SPI value is a good choice, because the AH header as well as the ESP header include the SPI field. Thus, the SPI value is be placed in the Responder Cookie field of the ISAKMP header during the SA negotiations, and when the SA negotiations are performed and the SA is available, the SPI value is placed in either the SPI field of the AH header or in the SPI field of the ESP. Because the Responder Cookie field is longer (64 bits) than the SPI field (32 bits), the SPI value fills only half of the Responder Cookie field.

A server cluster in accordance with the invention preferably operates as one network node in the IP network. Therefore, all members share the same public IP address. Each member may have three network interfaces. The first interface is intended for Internet communication, i.e. it is the public interface of the server cluster. The second interface is intended for Intranet communication, thus it can be considered as a private interface. The third interface is used for internal communication within the server cluster. Clustering may work without this, but it is better to have the third interface, because use of the private or public interface may lead to loss of clustering messages when the network load is high. The third interface transmits only internal cluster messages, so it can never be full.

FIG. 5 shows an example of a server cluster 501 that is composed of three members 502-504. Member 502 is a master, and the two other members are slaves. The cluster members are connected by at least one network, and each cluster member is equipped with at least one network card. Routers card. Routers 505 and 506, which are termed "next hop routers", see only one IP address of the cluster. The layer two address of the cluster is the master's address. If the master is changed, the next hop routers 505 and 506 must learn a new layer two address. The routing of IP packets is based on Address Resolution Protocol (ARP). In this example, an entity 507 uses a service 508 via the server cluster 501 so that there are one or more SAs between the entity and the server cluster.

A server cluster in accordance with the invention handles security packets. It is composed of a master server and at least one slave server. Preferably, the slave servers handle all the packets, but it is possible that also the master takes a part of the load and handles a part of the packets. The server cluster is adapted to receive a security packet belonging to the security association between an entity and the server cluster. The security packet includes a handler value originating from the server cluster. The server cluster is also adapted to determine the slave server with the handler number space to which said handler value belongs, and to transmit the security packet to said slave server. The security association may be created by a user. Alternatively, the security association is negotiated using negotiation packets.

For a security association negotiation the server cluster is adapted to receive a negotiation packet from the entity and to select a slave server. When a responder value included in the negotiation packet is a dummy value, the server cluster is adapted to select a responder value belonging to the responder number space addressed to the selected slave server.

The responder value may be selected by the master server. Then the master negotiates an SA and sends the first response negotiation packet to the entity. Alternatively, the selected slave server negotiates an SA. In that case, the master server transmits the negotiation packet to the selected slave which forms the first response negotiation and sends it to the entity. Thus, either the master or a slave may be responsible for the SA negotiation and send one or more negotiation packets to the entity.

Generally speaking, when the server cluster receives a negotiation packet in response to the first response negotiation packet, the negotiation packet received contains a responder value selected by the server cluster. In other words, the entity has read the responder value of the negotiation packet sent by the server cluster and the entity has placed the responder value in its negotiation packet. The master is adapted to determine which slave server has the responder number space that the responder value belongs to. The master then transmits a second "response" negotiation packet to said slave server.

In addition to the examples and the implementation alternations described above, there are other examples and implementation alternations which a man skilled in the art can find by using the teachings of this patent application.

Claims

1. A method for handling security packets sent by an entity in a server cluster composed of a master server and at least one slave server, said security packets belonging to a security association between the entity and the server cluster, characterized by the steps of: receiving at said master server a security packet belonging to the security association, said security packet containing a handler value which is originated from the server cluster and which is placed in the security packet by the entity, determining a slave server of the server cluster whose handler number space said handler value belongs to, and transmitting the security packet to said slave server.

2. The method as described in claim ^characterized in that the handler value is selected taking into account the load of each slave server.

3. The method as described in claim ^characterized in that the handler value is an integral number.

4. The method as described in claim ^characterized in that the security association is created by a user.

5. The method as described in claim ^characterized in that the security association is negotiated using negotiation packets.

6. The method as described in claim 5, characterized in that the server cluster performs the further steps of: receiving a negotiation packet from the entity, and when a dummy value is included in the negotiation packet, selecting a slave server, selecting a responder value which differs from the dummy value and which belongs to a responder number space addressed to the slave server selected, and in response to the negotiation packet received, sending a first response negotiation packet with the responder value to the entity.

7. The method as described in claim 5, characterized, when the responder value included in the negotiation packet differs from the dummy value, by the further steps of: determining the slave server whose responder number space said responder value belongs to and sending a second response negotiation packet with the responder value to the entity.

8. The method as described in claim 1 and 6, characterized in that the handler value and the responder value are the same value.

9. The method as described in claim ^characterized in that the security packets are Internet Protocol security (IPsec) packets.

10. The method as described in claim 5, characterized in that the negotiation packets are Internet Security Association and Key Management Protocol (ISAKMP) packets.

11. The method as described in claim 8, 9, and 10, characterized in that the same value is placed in the Security Parameters Index (SPI) field of the security packet and in the Responder Cookie field of the negotiation packet.

12. The method as described in claim 1, characterized in that the master server operates as a slave server.

13. A server cluster for handling security packets sent by an entity in a server cluster composed of a master server and at least one slave server, said security packets belonging to a security association between the entity and the server cluster, characterized in that the server cluster is adapted to: receive at said master server a security packet belonging to the security association, said security packet containing a handler value which is originated from the server cluster and which is placed in the security packet by the entity, determine a slave server of the server cluster whose handler number space said handler value belongs to, and transmit the security packet to said slave server.

14. The method as described in claim 13, characterized in that the handler value is selected taking into account the load of each slave server.

15. The method as described in claim 13, characterized in that the handler value is an integral number.

16. The server cluster as described in claim 13, characterized in that the security association is created by a user.

17. The server cluster as described in claim 13, characterized in that the security association is negotiated using negotiation packets.

18. The server cluster as described in claim 17, characterized in that the server cluster is further adapted to: receive a negotiation packet from the entity, and when a dummy value is included in the negotiation packet, select a slave server, select a responder value which differs from the dummy value and which belongs to a responder number space addressed to the slave server selected, and in response to the negotiation packet, send a first response negotiation packet with the responder value to the entity.

19. The server cluster as described in claim 18, characterized in that the responder value is selected by the master server and the master server sends the first response negotiation packet to the entity.

20. The server cluster as described in claim 18, characterized in that when the slave server is selected, the server cluster is further adapted to: transmit the negotiation packet from the master server to the slave server selected.

21. The server cluster as described in claim 18, characterized in that the responder value is selected by the slave server and the slave server sends the first response negotiation packet to the entity.

22. The server cluster as described in claim 18, characterized in that the server cluster is further adapted to: receive at the master server another negotiation packet with the responder value selected by the server cluster.

23. The server cluster as described in claim 18, characterized in that the server cluster is further adapted to: determine the slave server with the responder number space to which said responder value belongs, and transmit the other negotiation packet to said slave server.

24. The server cluster as described in claim 13 and 18, characterized in that the handler value and the responder value are the same value.

25. The server cluster as described in claim 13, characterized in that the security packets are Internet Protocol security (IPsec) packets.

26. The server cluster as described in claim 17, characterized in that the negotiation packets are Internet Security Association and Key Management Protocol (ISAKMP) packets.

27. The method as described in claim 24, 25, and 26, characterized in that the same value is placed in the Security Parameters Index (SPI) field of the security packet and in the Responder Cookie field of the negotiation packet.

28. The method as described in claim 13, characterized in that the master server operates as a slave server.