JP5296769B2 - History management method, history management apparatus, and history management system - Google Patents

Description

  The present invention relates to a history management method, a history management apparatus, and a history management system.

  There is a communication system that provides service information unique to a client device. For example, a description will be given using a communication system that executes a DHCP service based on DHCP (Dynamic Host Configuration Protocol). A communication system that executes a DHCP service includes a DHCP server and a DHCP client. Here, when an IP (Internet Protocol) address is requested from the DHCP client, the DHCP server issues an IP address with a valid period set to the DHCP client. That is, the DHCP server provides an IP address to the DHCP client during the validity period. The valid period of the IP address is also referred to as “lease period”.

  In the communication system that executes the DHCP service, even if the IP address is once provided to the DHCP client, the DHCP server provides it again to any DHCP client when the lease period ends.

  FIG. 13 is a diagram illustrating an example of a flow of IP address payout processing by the DHCP server. As shown in (1) of FIG. 13, the DHCP client transmits a “Discover signal” including a user identifier unique to the DHCP client to the DHCP server. That is, the DHCP client requests the DHCP server to issue information necessary for IP communication such as an IP address and a subnet mask. For example, the DHCP client transmits a Discover signal when power is turned on. Information necessary for IP communication such as an IP address and a subnet mask is also referred to as “IP setting information”.

  When the DHCP server receives the Discover signal from the DHCP client, the DHCP server extracts a user identifier from the Discover signal and determines a candidate IP address that can be issued to the DHCP client. Then, as shown in (2) of FIG. 13, the DHCP server transmits an “Offer signal” including the determined IP address candidate to the DHCP client.

  When the DHCP client receives the Offer signal from the DHCP server, the DHCP client confirms a candidate IP address included in the Offer signal. Then, as shown in (3) of FIG. 13, if the IP address candidate can be accepted, the DHCP client sends a “Request signal” including the user identifier to the DHCP server, and requests to secure the IP address. To do.

  Then, when the DHCP server receives the Request signal from the DHCP client, the DHCP server secures an IP address and holds it together with the user identifier included in the Request signal. Then, as shown in (4) of FIG. 13, the DHCP server transmits an ACK (ACKnowledgement) signal including the reserved IP address to the DHCP client. That is, the DHCP server provides the reserved IP address to the DHCP client during the lease period.

  Thereafter, when the DHCP client receives the ACK signal from the DHCP server, the DHCP client sets the IP address included in the received ACK signal to the network interface of the own device, and executes IP communication.

  The lease period is extended when a lease renewal request for updating the lease period is transmitted to the DHCP server by the DHCP client. The lease period ends when the DHCP client transmits a Release signal that returns an IP address to the DHCP server. In addition, when the provided IP address becomes a target of the DoS attack, the DHCP client may not make a lease renewal request or transmit a Release signal. In this case, the DHCP client requests a new IP address after the provision of the IP address currently in use or after sending a Release signal that returns the IP address, and obtains the newly acquired IP address. IP communication is performed using. In other words, the DHCP client discards the currently provided IP address and acquires and uses a new IP address.

“Dynamic Host Configuration Protocol” http: // www. ietf. org / rfc / rfc2131. txt BURTON H. Bloom. "Space / Time Trade-offs in Hash Coding with Allowable Errors." Communications of the ACM 13: 7 (1970), 422-426.

  However, the above-described conventional technique has a problem that provision of service information may be inappropriate. For example, a description will be given using a case where the DHCP client “A” uses the provided IP address “1” as a target of the DoS attack, discards the IP address “1”, and acquires a new IP address. In this case, the IP address “1” discarded by the DHCP client “A” can be provided, and the DHCP server may provide the IP address “1” again to the DHCP client “A”. As a result, the DHCP client “A” may continue to suffer damage from the DoS attack.

  The disclosed technology has been made in view of the above, and an object thereof is to provide a history management method, a history management apparatus, and a history management system that can appropriately provide service information.

  In one aspect, the disclosed history management device includes a service information providing unit that provides unique service information to the client device. In addition, the history management device includes a history storage unit that stores a history of the unique service information provided to the client device by the service information providing unit. In the history management device, the service information providing unit does not provide the unique service information that has been provided to the client device again for a predetermined period based on the history stored in the history storage unit.

  According to one aspect of the disclosed history management apparatus, there is an effect that service information can be appropriately provided.

FIG. 1 is a diagram illustrating an overview of a history management system according to the first embodiment. FIG. 2 is a diagram illustrating an example of the configuration of the DHCP server according to the first embodiment. FIG. 3 is a diagram illustrating an example of information stored in the payout information DB according to the first embodiment. FIG. 4 is a diagram illustrating an example of information stored in the payout history DB according to the first embodiment. FIG. 5 is a flowchart illustrating an example of a flow of providing processing by the service information providing unit according to the first embodiment. FIG. 6 is a flowchart illustrating an example of the flow of a regular update process performed by the DB update processing unit according to the first embodiment. FIG. 7 is a diagram illustrating an example of a flow of regular update processing by the DB update processing unit according to the first embodiment. FIG. 8 is a flowchart illustrating an example of update processing of the payout filter information by the DB update processing unit according to the first embodiment. FIG. 9 is a diagram illustrating an example of the update process of the payout filter information by the DB update processing unit according to the first embodiment. FIG. 10 is a flowchart illustrating an example of a detailed processing flow of search processing by the service information providing unit according to the first embodiment. FIG. 11 is a diagram illustrating an example of a detailed processing flow of search processing by the service information providing unit according to the first embodiment. FIG. 12 is a diagram showing that the history management apparatus is specifically realized using a computer as a program. FIG. 13 is a diagram illustrating an example of a flow of IP address payout processing by the DHCP server.

  Hereinafter, embodiments of the disclosed history management method, history management apparatus, and history management system will be described in detail with reference to the drawings. Note that the invention disclosed by this embodiment is not limited. Each embodiment can be appropriately combined within a range in which processing contents do not contradict each other.

  A history management system according to the first embodiment will be described. FIG. 1 is a diagram illustrating an overview of a history management system according to the first embodiment. As illustrated in FIG. 1, the history management system according to the first embodiment includes a DHCP server 100 and one or a plurality of DHCP clients 200. The DHCP server 100 is also referred to as a “history management device”, and the DHCP client 200 is also referred to as a “client device”.

  In the example illustrated in FIG. 1, the case where there are three DHCP clients 200 is illustrated as an example, but the number is not limited to this, and an arbitrary number may be used. For example, the number of DHCP clients 200 may be one or two, or any number of four or more. Further, the DHCP server 100 may be a DHCPv4 server, a DHCPv6 server, or an arbitrary version of a DHCP server.

  In the example illustrated in FIG. 1, the DHCP client 200 is connected to the DHCP server 100 via the network 10. The DHCP client 200 is a terminal used for the client. In the example illustrated in FIG. 1, the DHCP client 200 includes a communication unit 201.

  In the DHCP client 200, the communication unit 201 requests IP setting information from the DHCP server 100, and performs IP communication by setting the IP setting information provided by the DHCP server 100 in the network interface of the own device. That is, the communication unit 201 requests the DHCP server 100 to issue an IP address, and executes IP communication using the issued IP address.

  In the following description, the case where the IP address is paid out will be described. However, the present invention is not limited to this, and any identification information for identifying a terminal connected to the network may be used. The IP address may be an IPv4 address, an IPv6 address, or an arbitrary IP address. In the following, an IP address will be described as an example. However, the present invention is not limited to this, and a prefix may be used. For example, the IPv6 prefix indicates an address space of the upper 48 bits of the IPv6 address, not an address designated by 128 bits.

  The DHCP server 100 is connected to the DHCP client 200 via the network 10. The DHCP server 100 provides unique service information to the DHCP client 200. Specifically, the DHCP server 100 sets a valid period for the DHCP client 200 by exchanging a plurality of types of request signals and response signals having a series of relationships with the DHCP client 200. The IP setting information including the IP address is paid out. In the following, description will be made using a case where the DHCP client requests to issue an IP address and the DHCP server issues an IP address to the DHCP client.

  Here, the flow of IP address delivery processing by the DHCP server 100 will be briefly described. The DHCP client 200 requests the DHCP server 100 to issue an IP address by transmitting a Discover signal including a unique user identifier to the DHCP client 200 to the DHCP server 100. Thereafter, the DHCP server 100 extracts a user identifier from the Discover signal, determines a candidate IP address that can be issued to the DHCP client 200, and transmits an Offer signal including the determined IP address to the DHCP client 200. Subsequently, when receiving the Offer signal, the DHCP client 200 confirms the IP address candidate included in the Offer signal. If the confirmed IP address is acceptable, the DHCP client 200 sends a Request signal including the user identifier to the DHCP server 100. Send and request to secure IP address. When the DHCP server 100 receives the Request signal from the DHCP client 200, the DHCP server 100 secures an IP address and holds it together with the user identifier included in the Request signal. Further, the DHCP server 100 transmits an ACK signal including the reserved IP address to the DHCP client 200. That is, the DHCP server 100 provides the secured IP address to the DHCP client 200 during the lease period. After that, when receiving the ACK signal from the DHCP server 100, the DHCP client 200 sets the IP address included in the received ACK signal to the network interface of the own device, and executes IP communication.

  Here, the IP address provided by the DHCP server 100 can be provided again when the lease period ends or when the return is notified to the DHCP server 100 by the Release signal from the DHCP client 200. Become. For example, the case where the lease period of the IP address “1” provided to the DHCP client “A” ends will be described. Further, the case where the DHCP server requests an IP address from the DHCP client “B” will be described. In this case, the IP address “1” can be provided. For example, the DHCP server provides the IP address “1” to the DHCP client “B”.

  Further, as will be described in detail below, the DHCP server 100 stores a history of unique service information provided to the DHCP client 200. Further, the DHCP server 100 does not provide the unique service information that has been provided to the DHCP client 200 again for a predetermined period based on the history. In other words, the DHCP server 100 can provide the IP address for which the lease period has ended again after a predetermined period has elapsed.

  FIG. 2 is a diagram illustrating an example of the configuration of the DHCP server according to the first embodiment. In the example illustrated in FIG. 2, the DHCP server 100 includes a packet reception unit 101, a packet transmission unit 102, a payout information DB 111, a payout history DB 112, and a lease history management control unit 120.

  The packet receiving unit 101 receives a packet from the DHCP client 200 and transmits the received packet to the lease history management control unit 120. Further, the packet transmission unit 102 transmits the packet received from the DHCP client 200 to the DHCP client 200. The packet received by the packet receiving unit 101 or the packet transmitted by the packet transmitting unit 102 corresponds to, for example, a Discover signal, an Offer signal, a Request signal, an ACK signal, or the like.

  The payout information DB 111 is connected to the lease history management control unit 120. The payout information DB 111 stores data used for various processes by the lease history management control unit 120. The payout information DB 111 corresponds to, for example, a semiconductor memory element such as a random access memory (RAM), a read only memory (ROM), and a flash memory, or a hard disk or an optical disk.

  The payout information DB 111 stores unique service information provided to the DHCP client 200. Specifically, the payout information DB 111 stores a list of IP addresses that have been paid out to the DHCP client 200 and whose lease period has not ended.

  That is, it indicates that the IP address stored in the payout information DB 111 is provided to the DHCP client 200 and cannot be provided to other DHCP clients 200. In other words, it indicates that an IP address that is not stored in the payout information DB 111 is not provided to the DHCP client 200. The IP address that is not provided to the DHCP client 200 includes, for example, an IP address that has been provided to the DHCP client 200 and whose lease period has ended and provision to the DHCP client 200 has ended.

  FIG. 3 is a diagram illustrating an example of information stored in the payout information DB according to the first embodiment. As shown in FIG. 3, the payout information DB 111 stores a record including “payout address”, “payout time”, and “payout user name”. Here, the “payout address” indicates an IP address issued by the DHCP server 100. “Disbursement time” indicates the time when the DHCP server 100 pays out or the time when the IP address is secured. The “payout user name” indicates information for identifying the DHCP client 200 that is the payout destination to which the IP address is issued by the DHCP server 100.

  In the example shown in FIG. 3, the payout information DB 111 stores a record including a payout address “10.20.30.1”, a payout time “2010/1/1 12:32”, and a payout user name “U001”. That is, the payout information DB 111 stores that the IP address “10.20.30.1” has been paid out to “DHCP / 01” identified by “U001” at “2010/1/1 12:32”.

  Note that the information stored in the payout information DB 111 is updated by the lease history management control unit 120 as described later. Specifically, when the IP address is paid out by the lease history management control unit 120, the payout information DB 111 stores a new record including the paid out IP address. In the payout information DB 111, the lease history management control unit 120 deletes the record including the IP address whose lease period has ended.

  Returning to the description of FIG. The payout history DB 112 is connected to the lease history management control unit 120. The payout history DB 112 stores data used for various processes by the lease history management control unit 120. The payout information DB 111 corresponds to, for example, a semiconductor memory device such as a RAM, a ROM, and a flash memory, or a hard disk or an optical disk.

  The payout history DB 112 stores a history of unique service information provided to the DHCP client 200. The payout history DB 112 is also referred to as a “history storage unit”. Specifically, the payout history DB 112 stores a history of hash values of unique service information provided to the DHCP client 200. More specifically, the payout history DB 112 stores a history of unique service information provided to the DHCP client 200 in a hash filter Bloom filter format.

  FIG. 4 is a diagram illustrating an example of information stored in the payout history DB according to the first embodiment. The payout history DB 112 stores an arbitrary amount of history. Here, the payout history DB 112 may store a history of an arbitrary data capacity as an arbitrary amount, may store a history for an arbitrary time, and the IP address paid out to the user for each user. The IP addresses provided in the past may be stored as an arbitrary number of histories. In the following, description will be given using a case where the payout history DB 112 stores a history for an arbitrary time.

  As shown in FIG. 4, the payout history DB 112 stores a record including “payout period” and “payout filter information”. Here, “payout filter information” indicates a Bloom filter generated based on the hash value of the IP address paid out within the “payout period”. Hereinafter, the case where the payout filter information is “5000 bits” will be described. In other words, “payout filter information” is a history held in the Bloom filter format, and indicates a history of the hash value of the IP address that has been paid out. The record stored in the payout history DB 112 is updated by the lease history management control unit 120 as will be described later.

  The Bloom filter generated based on the hash value of the IP address paid out during the payout period will be briefly described. For example, description will be made using a case where the number of issued IP addresses is “10” and the hash value of the IP address generated by the hash function is “1 to 5000”. Further, a description will be given using a case where “3” hash values are calculated using “3” hash functions for each IP address issued. In this case, the bit corresponding to the hash value calculated for each of the 10 IP addresses is “1”. More specifically, three hash values are calculated for each of the 10 IP addresses, and 30 hash values are calculated. Then, the bit corresponding to each of the calculated 30 hash values is updated to “1”. Even if a plurality of identical hash values are calculated, the bit is updated to “1”.

  In the example illustrated in FIG. 4, the payout history DB 112 has shown a case where records having a payout period of “1 hour” are stored for the latest 10 hours. For example, the payout history DB 112 stores each record in which the payout period is “1 hour” for 10 hours from “2010/1/1 10:00” to “2010/1/1 20:00”. For example, the payout history DB 112 stores a record including a payout period “2010/1/1 10:00 11:00” and payout filter information “010001100100... 110”. In other words, the payout history DB 112 stores a history of hash values calculated for each IP address assigned on “2010/1/1 10:00 11:00” in a Bloom filter format. The payout filter information is “010001100100... 110”, and the second bit, the sixth bit, the seventh bit, and the like are “1”. For this reason, the payout history DB 112 indicates that the hash value of the IP address issued during the payout period “2010/1/1 10:00 11:00” is “2”, “6”, “7”, etc. Remember that there is.

  In the following, description will be made using a case where a maximum of “1000 times” IP addresses are issued per hour by the DHCP server 100, the payout filter information is “5000” bits, and “3” hash functions are used. Note that the significance of using three hash functions when the IP address is issued up to 1000 times per hour by the DHCP server 100 and the payout filter information is 5000 bits will be described later and will not be described here. .

  In the following description, the payout history DB 112 will be described using a case where records with a payout period of 1 hour are stored for the last 10 hours, but the present invention is not limited to this. For example, in the payout history DB 112, the payout period may be an arbitrary period shorter than 1 hour, and the payout period may be an arbitrary period longer than 1 hour. Further, for example, the payout history DB 112 may store records for an arbitrary time shorter than the latest 10 hours, or may store records for an arbitrary time longer than the latest 10 hours.

  In the following description, a case where a maximum of “1000 times” IP addresses are paid out per hour, the payout filter information is “5000” bits, and “3” hash functions are used will be described. It is not limited. For example, the DHCP server 100 may issue an arbitrary number of IP addresses more than the maximum “1000 times” per hour, or an arbitrary number of IP addresses less than the maximum “1000 times” per hour. May be. Further, for example, the payout filter information may be an arbitrary number of bits greater than “5000” bits, and the payout filter information may be an arbitrary number of bits less than “5000” bits. For example, an arbitrary number of hash functions greater than “3” may be used, and an arbitrary number of hash functions smaller than “3” may be used.

  Returning to the description of FIG. The lease history management control unit 120 is connected to the packet reception unit 101, the packet transmission unit 102, the payout information DB 111, and the payout history DB 112. The lease history management control unit 120 has an internal memory that stores a program that defines various processing procedures and the like, and controls various processes. The lease history management control unit 120 corresponds to, for example, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a central processing unit (CPU), and a micro processing unit (MPU). In the example illustrated in FIG. 2, the lease history management control unit 120 includes a service information providing unit 121 and a DB update processing unit 122.

  When the packet receiving unit 101 receives the Discover signal from the DHCP client 200, the service information providing unit 121 provides unique service information to the DHCP client 200. Specifically, the service information providing unit 121 exchanges a plurality of types of request signals and response signals having a series of relationships with the DHCP client 200 connected via the network, so that the client device Provide an IP address. Here, the request signal and the response signal are a Discover signal, an Offer signal, a Request signal, an ACK signal, and the like.

  Further, when the service information providing unit 121 provides the IP address to the DHCP client 200, the service information providing unit 121 indicates the provided IP address, a payout user name for identifying the DHCP client 200 to be provided, and a time when the IP address is issued. A record including the payout time is stored in the payout information DB 111. Note that an example of a detailed flow of processing by the service information providing unit 121 will be described later using a flowchart, and description thereof will be omitted here.

  The IP address issued by the service information providing unit 121 will be further described. As described above, the IP address provided by the DHCP server 100 can be provided again by the DHCP server 100 when the lease period ends. In other words, after being provided to the DHCP client 200, when the lease period ends and the provision of the IP address ends, the DHCP client 200 can be provided. Here, the service information providing unit 121 does not provide the unique service information that has been provided to the DHCP client 200 again for a predetermined period based on the history stored in the payout history DB 112. In other words, the service information providing unit 121 allows the IP address provided to the DHCP client 200 to be provided again after a predetermined period has elapsed for the IP address whose lease period has ended.

  In the following, the case where the service information providing unit 121 does not pay out the same IP address again for a predetermined period on the basis of the payout time when the IP address is issued to the DHCP client 200 will be described. Specifically, the service information providing unit 121 provides IP addresses that have not been paid out for a predetermined period based on the payout history DB 112 among IP addresses that are not stored in the payout information DB 111.

  More specifically, the service information providing unit 121 calculates a hash value for an arbitrary IP address among IP addresses that are not stored in the payout information DB 111, and a Bloom filter in which the calculated hash value is stored in the payout history DB 112 Service information is not provided if they match, and is provided if they do not match. That is, the service information providing unit 121 does not provide the IP address again during a period in which a history indicating that the payout history DB 112 has been paid out is stored.

  Here, the hash function used by the service information providing unit 121 is the same as the hash function used when updating the Bloom filter. For example, when three hash values are calculated using three hash functions when updating the Bloom filter for each IP address that has been issued, the service information providing unit 121 uses the three hashes used when updating the Bloom filter. Three hash values are calculated using the function. Then, the service information providing unit 121 does not provide an IP address when there is a record in the payout history DB 112 that matches all the calculated hash values, and provides an IP address when there is no record.

  The DB update processing unit 122 updates the payout information DB 111. Specifically, the DB update processing unit 122 deletes the record including the IP address whose lease period has ended from the records stored in the payout information DB 111. For example, the DB update processing unit 122 periodically refers to the payout information DB 111, compares the payout time with the current time, and deletes records that have passed a predetermined lease period or longer.

  Further, the DB update processing unit 122 updates the payout history DB 112. The DB update processing unit 122 executes periodic update processing of the payout history DB 112 and executes payout filter information update processing. The case where the payout history DB 112 stores a record with a payout period of 1 hour for the last 10 hours will be further described as an example. First, regular update processing by the DB update processing unit 122 will be described. The DB update processing unit 122 deletes records that have passed 10 hours from the records stored in the payout history DB 112. In addition, the DB update processing unit 122 creates a new record with a payout period of 1 hour and stores it in the payout history DB 112. That is, the DB update processing unit 122 executes update processing so that the payout history DB 112 stores 10 hours of records.

  Next, the update processing of the payout filter information by the DB update processing unit 122 will be described. The DB update processing unit 122 updates the Bloom filter stored in the payout filter information of the DB update processing unit 122 using the hash value of the IP address that has been paid out during the hour set as the payout period. For example, when the service information providing unit 121 provides an IP address, the DB update processing unit 122 calculates a hash value of the IP address using a hash function prepared in advance, and uses the calculated hash value. The payout filter information of the DB update processing unit 122 is updated.

  Here, each bit of the payout filter information for explaining the relationship between the number of bits of the payout filter information in the payout history DB 112 and the hash function used by the DB update processing unit 122 is determined by the hash function used by the DB update processing unit 122. This indicates the calculated hash value. For this reason, when the number of bits of the payout filter information in the payout history DB 112 is “5000” bits, the DB update processing unit 122 uses a hash function whose hash values are “1” to “5000”.

  The number of hash functions used by the DB update processing unit 122 will be described. In other words, how many hash values are calculated for each issued IP address will be described. As a premise, a case will be described in which an IP address is issued 1000 times per hour at maximum and the number of bits of the payout filter information is 5000 bits. In this case, theoretically, the number of hash functions to be prepared is “ln2 × 5000 / 1000≈3” from the viewpoint of minimizing the false detection rate. Based on this, the DB update processing unit 122 prepares three types of hash functions in advance, and calculates three hash values for each IP address issued. For example, based on a hash function such as SHA1 (Secure Hash Algorithm 1), three types of hash functions with output hash values “1” to “5000” are prepared.

  Note that details of the regular update processing by the DB update processing unit 122 and details of the update processing of the payout filter information will be described later with reference to a flowchart, and thus the description thereof is omitted here.

[Provision processing by the service information provider]
An example of the flow of provision processing by the service information provision unit 121 according to the first embodiment will be described with reference to FIG. FIG. 5 is a flowchart illustrating an example of a flow of providing processing by the service information providing unit according to the first embodiment.

  As shown in FIG. 5, when the packet receiving unit 101 receives a Discover signal from the DHCP client 200 (Yes at Step S101), the service information providing unit 121 randomly determines an arbitrary IP address that is not stored in the payout information DB 111. (Step S102). For example, the service information providing unit 121 determines the IP address “10.20.30.5”.

  Then, the service information providing unit 121 executes search processing by referring to the payout information DB 111 (step S103). Specifically, the service information providing unit 121 determines whether or not the determined IP address is included in the payout filter information for each record in the payout information DB 111. The IP address included in the record stored in the payout information DB 111 is an IP address that has been paid out within a predetermined period in the past. Based on this, the service information providing unit 121 determines whether or not the determined IP address has been paid out for a predetermined period.

  If the service information providing unit 121 determines that the service information is included (Yes at Step S104), the service information providing unit 121 discards the determined IP address, returns to Step S102, and repeats the process. That is, when it is determined that the arbitrary IP address determined in step S102 has been paid out within a predetermined period, the service information providing unit 121 again randomly selects an arbitrary IP address that is not stored in the payout information DB 111. The process is repeated until it is determined in step S103 that it is not included. Note that the service information providing unit 121 may determine the IP address after removing the IP address determined to be included when determining the IP address at random again.

  On the other hand, if it is determined that the service information providing unit 121 does not include the service information (No in step S104), the service information providing unit 121 stores a record including the determined IP address in the payout information DB 111 (step S105). That is, when it is determined that the arbitrary IP address determined in step S102 has not been paid out within the predetermined period, the service information providing unit 121 stores the determined IP address “10.20.30.5” as the payout address. The payout time is stored as the payout time, and the payout user name for identifying the DHCP client 200 as the payout destination is stored.

  In addition, the DB update processing unit 122 executes a payout filter information update process on the payout history DB 112 (step S106). Specifically, the DB update processing unit 122 updates the payout filter information of the record corresponding to the current time among the records stored in the payout history DB 112. That is, when the service information providing unit 121 provides an IP address, the DB update processing unit 122 calculates a hash value of the provided IP address and updates the payout filter information of the DB update processing unit 122.

  Then, the service information providing unit 121 transmits an Offer signal including the determined IP address to the DHCP client 200 via the packet transmission unit 102 (step S107). After that, when the packet receiving unit 101 receives the Request signal, the service information providing unit 121 performs payout based on the IP address determined when the Discover signal is received.

  In the example illustrated in FIG. 5, the DHCP server 100 has been described using the case where the payout information DB 111 and the payout history DB 112 are updated after receiving the Discover signal and before transmitting the Offer signal. Is not to be done. For example, it may be updated after transmitting the Offer signal, may be updated after receiving the Request signal, or may be updated after transmitting the Ack signal.

[Periodic update process by DB update processor]
An example of the flow of regular update processing by the DB update processing unit 122 according to the first embodiment will be described with reference to FIGS. 6 and 7. FIG. 6 is a flowchart illustrating an example of the flow of a regular update process performed by the DB update processing unit according to the first embodiment. FIG. 7 is a diagram illustrating an example of a flow of regular update processing by the DB update processing unit according to the first embodiment. In FIG. 7, tables 301 to 303 show an example of information stored in the payout history DB 112. Hereinafter, the case where the current time is “2010/1/1 20:00” will be described.

  As shown in FIG. 6, when the DB update processing unit 122 comes to the regular update timing (Yes at Step S201), the DB update processing unit 122 has a payout period of 10 hours or more among the records stored in the payout history DB112. The record being searched is searched (step S202), and the record that is the search result is deleted (step S203). The payout history DB 112 executes the above-described processing every hour, for example.

  That is, for example, in the example shown by 301 and 302 in FIG. 7, the DB update processing unit 122 performs the payout period “2010 / A record including “1/1 10:00 11:00” and the payout filter information “010001100100... 110” is deleted. In FIG. 7, 301 indicates the payout history DB 112 before deletion by the DB update processing unit 122, and 302 indicates the payout history DB 112 after deletion by the DB update processing unit 122.

  Then, the DB update processing unit 122 stores in the payout history DB 112 a new record whose payout period is 1 hour from the current time (step S204). Here, the DB update processing unit 122 stores information initialized with “0” as the payout filter information of the newly stored record. That is, for example, as shown by 303 in FIG. 7, a record having a payout period “2010/1/1 20: 00-21: 00” is newly stored, and the payout filter information wp “00. And all “0”.

  Note that the above-described processing procedure is not limited to the above-described order, and may be appropriately changed within a range that does not contradict the processing contents. For example, the above step S204 may be executed before S202 and 203.

[Update processing of payout filter information by DB update processing unit]
An example of the update process of the payout filter information by the DB update processing unit 122 according to the first embodiment will be described with reference to FIGS. 8 and 9. FIG. 8 is a flowchart illustrating an example of update processing of the payout filter information by the DB update processing unit according to the first embodiment. A series of processing shown in FIG. 8 corresponds to step S106 in FIG. FIG. 9 is a diagram illustrating an example of the update process of the payout filter information by the DB update processing unit according to the first embodiment. A series of numeric strings shown in FIG. 9 indicates the payout filter information of the payout history DB 112. Specifically, a bit string 311 in FIG. 9 indicates payout filter information before update processing of the payout filter information by the DB update processing unit 122, and a bit string 312 indicates payout filter information after the update process. Hereinafter, a case where the IP address “10.20.30.5” is issued by the service information providing unit 121 will be described as an example.

  As illustrated in FIG. 8, the DB update processing unit 122 calculates a hash value for a provided IP address using a hash function prepared in advance (Step S <b> 301). For example, when three types of hash functions are prepared in advance, the hash value of the IP address “10.20.30.5” is calculated for each of the three types of hash functions.

  Then, the DB update processing unit 122 updates the bit corresponding to the calculated hash value to “1” in the payout filter information of the record corresponding to the current time among the records stored in the payout history DB 112 (step S302). ). For example, the case where the hash values calculated by the DB update processing unit 122 are “2770”, “100”, and “1550” will be described. In this case, as shown in FIG. 9, the DB update processing unit 122 updates the 2770th bit to “1” and sets the 100th bit in the payout filter information of the record corresponding to the current time. The bit is updated to “1”, and the 1550th bit is updated to “1”. Here, when the bit corresponding to the calculated hash value is already “1”, the DB update processing unit 122 is left as it is.

[Search processing by the service information provider]
An example of a detailed processing flow of search processing by the service information providing unit 121 according to the first embodiment will be described with reference to FIGS. 10 and 11. FIG. 10 is a flowchart illustrating an example of a detailed processing flow of search processing by the service information providing unit according to the first embodiment. FIG. 11 is a diagram illustrating an example of a detailed processing flow of search processing by the service information providing unit according to the first embodiment. FIG. 11 shows an example of payout filter information stored in the payout history DB 112 when the search processing by the service information providing unit 121 is executed.

  A series of processing described below corresponds to the search processing in step S103 in FIG. Hereinafter, the case where the service information providing unit 121 determines the IP address “10.20.30.5” in step S102 of FIG. 5 will be described.

  As illustrated in FIG. 10, the service information providing unit 121 calculates a hash value for the determined IP address using a hash function prepared in advance (step S401). Here, the hash function used by the service information providing unit 121 is the same as the hash function used when the DB update processing unit 122 updates the payout filter information.

  For example, as with the DB update processing unit 122, the service information providing unit 121 uses three hash functions to determine three hash values “2770”, “100”, and “100” for the determined IP address “10.20.30.5”. 1550 "is calculated.

  Then, the service information providing unit 121 refers to each of the payout filter information in the payout history DB 112 and determines whether all the bits corresponding to the hash value are set to “1” (Step S402). For example, as shown in FIG. 11, the service information providing unit 121 sets “2770” bit, “100” bit, and “1550” bit of the payout filter information for all records in the payout history DB 112. For all the bits, it is determined whether the bit is “1”.

  Here, as shown in FIG. 11, when it is determined that there is at least one record in the payout history DB 112 that is determined to have payout filter information in which all the bits corresponding to the hash value are set to “1”. This will be described (Yes at step S403). In this case, the service information providing unit 121 determines that the determined IP address is included in the payout filter information (step S404). That is, the service information providing unit 121 determines that the determined IP address has been paid out within the past predetermined period.

  On the other hand, a case will be described in which it is determined that there is no payout filter information in which all the bits corresponding to the hash value are set to “1” in the payout history DB 112 (No in step S403). In this case, the service information providing unit 121 determines that the determined IP address is not included in the payout filter information (step S405). That is, the service information providing unit 121 determines that the determined IP address has not been paid out within the past predetermined period.

[Effect of Example 1]
As described above, according to the first embodiment, the DHCP server 100 provides unique service information to the DHCP client 200 and stores a history of unique service information provided to the DHCP client 200. Further, the DHCP server 100 does not provide the unique service information that has been provided to the DHCP client 200 again for a predetermined period based on the history stored in the payout history DB 112. As a result, service information can be appropriately provided.

  For example, even if the DHCP client 200 discards the provided IP address as a result of the DoS attack, the discarded IP address is not immediately provided to the own device, and the service information Can be provided appropriately. Further, the discarded IP address is not immediately provided to other DHCP clients 200, and the service information can be appropriately provided.

  For example, a description will be given using a case where the DHCP client “A” uses the provided IP address “1” as a target of the DoS attack, discards the IP address “1”, and acquires a new IP address. In this case, as a result of the DHCP server 100 not providing the IP address “1” discarded by the DHCP client “A” for a predetermined period, the IP address “1” is not provided to the DHCP client “A”. As a result, it is possible to prevent the DHCP client “A” from being continuously damaged by the DoS attack.

  Further, for example, a description will be given using a case where the DHCP client “A” has the provided IP address “1” as a target of the DoS attack, discards the IP address “1”, and acquires a new IP address. Further, the case where the DHCP server requests an IP address from the DHCP client “B” will be described later. In this case, as a result of the DHCP server 100 not providing the IP address “1” for a predetermined period, the IP address “1” is not provided to the DHCP client “B”. As a result, it is possible to prevent the DHCP client “B” from being damaged by the DoS attack following the DHCP client “A”.

  Further, according to the first embodiment, the payout history DB 112 stores a hash value history of unique service information provided to the DHCP client 200 by the service information providing unit 121. As a result, it is possible to reduce the amount of memory used in the DHCP server 100 and increase the efficiency of the search process as compared with the method of storing the history of the IP address itself. That is, the DHCP server 100 can efficiently manage the history of service information delivered to the DHCP client 200. Further, in the DHCP server 100, it is possible to reduce the load of history search for searching the history of service information paid out to the DHCP client 200.

  Further, according to the first embodiment, the payout history DB 112 stores the history of the hash value of the unique service information provided to the DHCP client 200 by the service information providing unit 121 as a Bloom filter. As a result, it is possible to reduce the memory usage in the DHCP server 100 and increase the efficiency of the search process by keeping the IP address payout history in the Bloom filter format instead of leaving it in time series.

  Although the embodiments of the present invention have been described so far, the present invention may be implemented in other embodiments besides the above-described embodiments. Therefore, other embodiments will be described below.

[Payout history DB]
For example, in the above-described embodiment, the case where the payout history DB 112 stores the history in the Bloom filter format has been described, but is not limited thereto. For example, the payout history DB 112 may store the payout IP address itself as a history, or may store the hash value itself calculated from the payout IP address as a history.

  Further, for example, in the above-described embodiment, the DB update processing unit 122 periodically updates the payout history DB 112 and the DB update processing unit 122 stores the records for a predetermined period. However, the present invention is not limited to this. For example, the DB update processing unit 122 does not update records for a predetermined period so that the DB update processing unit 122 stores them, and the service information providing unit 121 executes a search process at a predetermined period. After extracting the corresponding record, the search process may be executed on the extracted record.

[Lease term end criteria]
Further, for example, in the above-described embodiment, the case where the payout filter information of the payout history DB 112 is a Bloom filter generated by the hash value of the IP address paid out within the “payout period” has been described. In other words, the case has been described where the service information providing unit 121 does not pay out the same IP address again for a predetermined period on the basis of the payout time when the IP address is issued to the DHCP client 200. However, it is not limited to this.

  For example, the payout filter information in the payout history DB 112 may be a Bloom filter generated from the hash value of the IP address whose lease period has ended within the “payout period”. In other words, the service information providing unit 121 may not pay out the same IP address again for a predetermined period on the basis of the end of the lease period.

[History]
For example, in the above-described embodiment, the payout history DB 112 stores an arbitrary amount of history, and the IP address that has been provided to the DHCP client 200 is not provided for a period included in the history stored in the payout history DB 112. The case where the information is not provided again for a predetermined period has been described. In this case, for example, when an IP address is paid out to the DHCP client “A”, it is stored in the payout history DB 112 without distinguishing between the history of the DHCP client “A” and the history of the other DHCP client 200. The case where the period included in the recorded history is not provided has been described. However, it is not limited to this.

  For example, after distinguishing which user the history is about, the period included in the history stored in the payout history DB 112 may not be provided. In this case, the payout history DB 112 stores an arbitrary amount of history of IP addresses that have been paid out in the past in association with payout user names. Then, the lease history management control unit 122 does not provide the information again for a predetermined period based on the history of the user to whom the IP address is provided.

  To explain with a more detailed example, when an IP address is issued to the DHCP client “A”, the IP address previously provided to the DHCP client “A” is referred to by referring to the history of the DHCP client “A”. Do not provide for any period of time.

  In the above description, the case where the payout history DB 112 stores a history for each user has been described. However, the present invention is not limited to this. For example, an arbitrary amount of history may be stored in the payout information DB 111. For example, the payout information DB 111 may store an IP address provided before an arbitrary generation in association with the payout user name. Then, the lease history management control unit 122 may not provide the user who is the payout destination with the IP address provided before any generation based on the history for each user stored in the payout information DB 111. . In this case, the DHCP server 100 may not use the payout history DB 112.

[System configuration]
Also, among the processes described in this embodiment, all or part of the processes described as being performed automatically can be performed manually, or the processes described as being performed manually can be performed. All or a part can be automatically performed by a known method. For example, the user may manually execute the periodic update process of the payout history DB 112.

  In addition, the processing procedures, control procedures, specific names, and information including various data and parameters shown in the above-mentioned document and drawings (FIGS. 1 to 11) are arbitrarily changed unless otherwise specified. be able to.

  Further, each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. That is, the specific form of distribution / integration of each device is not limited to the one shown in the figure, and all or a part of the distribution / integration may be functionally or physically distributed in arbitrary units according to various loads or usage conditions. Can be integrated and configured. For example, the payout information DB 111 and the payout history DB 112 may be connected as an external device of the DHCP server 100 via a network. Also, the payout information DB 111 and the payout history DB 112 may be integrated into one storage unit.

[program]
FIG. 12 is a diagram showing that the above-described history management device is specifically realized using a computer as a program. As illustrated in FIG. 12, the computer 3000 includes, for example, a memory 3010, a CPU (Central Processing Unit) 3020, a network interface 3070, and a hard disk drive 3080. Each part of the computer 3000 is connected by a bus 3100.

  The memory 3010 includes, for example, a ROM and a RAM 3012. The ROM of the memory 3010 stores a boot program such as BIOS (Basic Input Output System).

  Further, the hard disk drive 3080 stores, for example, an OS 3081, an application program 3082, a program module 3083, and program data 3084. In other words, the update program according to the disclosed technology is stored in, for example, the hard disk drive 3080 as the program module 3083 in which instructions executed by the computer are described. Specifically, a program module describing each procedure for executing the same information processing as the lease history management control unit 120 described in the above embodiment is stored in the hard disk drive 3080.

  In addition, data used for information processing by the history management program, such as information stored in the payout information DB 111 and information stored in the payout history DB 112 described in the above embodiment, is, for example, hard disk drive 3080 as program data 3084. Is remembered. The CPU 3020 reads the program module 3083 and program data 3084 stored in the hard disk drive 3080 to the RAM 3012 as necessary, and executes various procedures.

  Note that the program module 3083 and the program data 3084 related to the history management program are not limited to being stored in the hard disk drive 3080. For example, the program module 3083 and the program data 3084 may be stored in a removable storage medium. In this case, the CPU 3020 reads data via a removable storage medium such as a disk drive. Similarly, the program module 3083 and program data 3084 related to the update program may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). . In this case, the CPU 3020 reads various data by accessing another computer via the network interface.

[Others]
The history management program described in the present embodiment can be distributed via a network such as the Internet. The history management program can also be executed by being recorded on a computer-readable recording medium such as a hard disk, a flexible disk (FD), a CD-ROM, an MO, or a DVD, and being read from the recording medium by the computer.

100 DHCP server 101 packet receiving unit 102 packet transmitting unit 112 payout history DB
111 payout information DB
120 Lease history management control unit 121 Service information providing unit 122 DB update processing unit 200 DHCP client 201 communication unit

Claims (11)

Computer
A service information providing step of providing unique service information to the client device;
A storage step of storing the history of the unique service information provided to the client device by the service information providing step in a history storage unit in association with identification information for identifying the client device to be provided ;
In the service information providing step, the unique service information that has been provided to the client device is associated with identification information that identifies a client device as a providing destination , based on a history stored in the history storage unit, A history management method, wherein the same client device is not provided again for a predetermined period. The history storage unit stores a predetermined amount of history,
The service information providing step, the said specific service information providing is completed for the client device, by not providing the period included the specific service information on the history stored in the history storage unit, the predetermined time period The history management method according to claim 1, wherein the history management method is not provided again. The service information providing step, wherein based on the history storage unit for storing a history of the hash value of the specific service information provided to the client device does not provide the specific service information said predetermined time period again The history management method according to claim 2. The service information providing step, based on the history storage unit for storing a history of the hash value of the specific service information provided to the client device as a bloom filter, do not provide the specific service information said predetermined time period again The history management method according to claim 3. The computer is a DHCP (Dynamic Host Configuration Protocol) server,
The service information providing step connects the client device to the network by exchanging a plurality of types of request signals and response signals having a series of relationships with the client device connected via the network. 5. The history management method according to claim 1, further comprising providing identification information for identifying a terminal to be executed. A service information providing unit for providing unique service information to the client device;
A history storage unit for storing the history of the unique service information provided to the client device by the service information providing unit in association with identification information for identifying a client device as a provision destination ;
The service information providing unit, based on the history stored in the history storage unit in association with the identification information for identifying the client device as a providing destination , the unique service information that has been provided to the client device , A history management device, wherein the same client device is not provided again for a predetermined period. The history storage unit stores a predetermined amount of history,
The service information providing unit, the said specific service information providing is completed for the client device, by not providing the period included the specific service information on the history stored in the history storage unit, the predetermined time period The history management device according to claim 6, wherein the history management device is not provided again.   The history management device according to claim 7, wherein the history storage unit stores a history of hash values of unique service information provided to the client device by the service information providing unit.   The history management device according to claim 8, wherein the history storage unit stores a history of hash values of unique service information provided to the client device by the service information providing unit as a Bloom filter. The history management device is a DHCP (Dynamic Host Configuration Protocol) server,
The service information providing unit connects the client device to the network by exchanging a plurality of types of request signals and response signals having a series of relationships with the client device connected via the network. The history management apparatus according to claim 6, wherein identification information for identifying a terminal to be used is provided. A history management system having a client device and a DHCP (Dynamic Host Configuration Protocol) server,
The DHCP server is
A service information providing unit for providing identification information for identifying a terminal connected to the network to the client device;
A history storage unit for storing the history of the unique IP address provided to the client device by the service information providing unit in association with identification information for identifying a client device as a providing destination ;
The service information providing unit, based on the history stored in the history storage unit in association with the identification information for identifying the client device serving as the providing destination , the identification information that has been provided to the client device is the same Do not provide the client device again for a predetermined period,
The history management system, wherein the client device includes a communication unit that performs communication using identification information provided by the service information providing unit.

Images