JP2008244765A - Dynamic host configuration protocol server and IP address assignment method - Google Patents

Abstract

An IP address can be provided only to an authenticated user without requiring a special function for a terminal network device to which a client terminal is connected.
An authentication DHCP server has an address management table used for managing an authentication state of the client terminal in association with a physical address of the client. The authentication processing unit 16 of the server 1 relays authentication data transmitted from a client not assigned an IP address to the authentication server to perform authentication. The DHCP processing unit 17 of the server 1 assigns an IP address to the client terminal managed as authenticated by the address management table 11 as a result of successful request authentication. The ARP processing unit 15 of the server 1 returns a fake ARP response to the ARP request from the client that has not been authenticated.
[Selection] Figure 1

Description

  The present invention relates to a dynamic host configuration protocol server for assigning an IP address to a client terminal connected to a network, and an IP address assignment method.

  A DHCP (Dynamic Host Configuration Protocol) server is known as a server that dynamically distributes (assigns) an address (IP address) to a client (client terminal) that communicates via a network. . However, the DHCP applied by the DHCP server does not have the concept of user authentication in the protocol, and therefore cannot distribute an IP address only to authenticated users.

  As a method for restricting access to a client using DHCP, a method using an authentication switch based on 802.1x defined by IEEE is known. In 802.1x, communication between the authentication switch and the client is performed by setting a frame called EAPOL (EAP Over LAN) in the payload of the data link layer without using an IP header. In the data part of EAPOL, data obtained by encapsulating authentication data with EAP (Extensible Authentication Protocol) defined in EAPRFC 2284 is stored. Communication between the authentication switch and the authentication server is performed via a network (for example, a backbone LAN) using the IP address of the authentication switch and the IP address of the authentication server.

  Regarding the authentication protocol, the authentication switch converts the EAPOL packet transmitted by the client into an IP packet and relays it to the authentication server via the network, while converting the IP packet transmitted from the authentication server via the backbone LAN into an EAP packet. Relay to the client.

  Here, the authentication switch is set to discard all communication packets of the authentication packet until the user authentication is completed. When the client connects to the authentication switch, the authentication switch transmits an authentication request (EAP Identity Request) to the client. When the client receives the authentication request from the authentication switch, the client sends an authentication response (EAP Identity Reply) to the authentication switch.

  The authentication switch transfers the authentication response from the client to the authentication server using the IP address of the authentication switch and the IP address of the authentication server. Thereby, the authentication protocol is executed in the authentication server.

  When the authentication by the authentication server is successful, the authentication switch makes the client port connectable to the network. In this state, the client obtains an IP address from the DHCP server and becomes communicable with the network. As described above, according to the method using the authentication switch based on 802.1x, the user can be authenticated before the client acquires the IP address from the DHCP server.

  In the above description, one authentication switch exists between the client and the network, but a plurality of authentication switches are generally connected to the network in a hierarchical manner.

  As another method for restricting access to a client using DHCP, for example, a method using an authentication VLAN (Virtual LAN) as described in Patent Document 1 is also known. In the method described in Patent Document 1, a VLAN-compatible switch is used. This switch sets all ports to a VLAN that can be connected only to a DHCP server and an authentication server. When a client is connected to the VLAN, the DHCP server provides the client with an IP address (authentication IP address) for authentication with the authentication server. Then, the client performs authentication (user authentication) with the authentication server using this authentication IP address.

If the authentication is successful, the authentication server causes the DHCP server to distribute an IP address communicable with a machine on the network to the client. Further, the authentication server connects the port to which the client is connected to the switch to a VLAN connectable to the network. As a result, the client obtains an IP address from the DHCP server and becomes communicable with the network.
JP 2004-64204 A

  In the above-described method using the authentication switch, the authentication switch relays the authentication process between the client and the authentication server, so that the switch itself must be able to process the authentication protocol. In other words, the terminal network device to which the client is connected must be an authentication switch (corresponding to an authentication protocol). For this reason, at the time of system construction, all the terminal network devices must be switched to the authentication switch (authentication hub), which increases the load of device replacement. Similarly, in the method using the authentication VLAN, the terminal network device needs to support the VLAN.

  The present invention has been made in consideration of the above circumstances, and its purpose is to authenticate a user who is authenticated in an environment using a dynamic host configuration protocol without requiring a special function for a terminal network device to which a client terminal is connected. It is an object to provide a dynamic host configuration protocol server and an IP address assignment method that can provide an IP address only for the server.

  According to one aspect of the present invention, a dynamic host configuration protocol server that assigns an IP address to a client terminal connected to a network is provided. The dynamic host configuration protocol server includes a management table that holds an authentication state of the client terminal in association with a physical address of the client terminal connected to the network, and a network interface that transmits / receives communication data to / from the network Relay means for relaying authentication data transmitted from a client terminal connected to the network and not assigned an IP address for requesting authentication to an authentication server connected to the network via the network interface; When the authentication server notifies that the authentication requested from the client terminal is successful, the authentication state stored in the management table is associated with the physical address of the client terminal that requested the authentication. ,Authenticated Authentication processing means for setting the status to be indicated, IP address assignment means for assigning an IP address to the client terminal of the physical address held in the management table in association with the authentication status set to the status indicating the authenticated status, When an address resolution protocol request transmitted by broadcast from a client terminal connected to the network is received by the network interface, the client terminal that has transmitted the address resolution protocol request with reference to the management table The address to send a fake address resolution protocol response via the network interface to the client terminal that has sent the address resolution protocol request if it is not authenticated. Comprising a determined protocol processing means.

  According to the present invention, the dynamic host configuration protocol server has the management table for managing the authentication state of the client terminal in association with the physical address of the client terminal, and transmitted from the client terminal to which the IP address is not assigned. The authentication data is relayed to the authentication server to perform authentication, and as a result of successful authentication requested from the client terminal (that is, after the authentication is completed), an IP address is assigned to the client terminal that has been authenticated by the management table By providing a function and a function of interrupting communication by returning a fake ARP response to an address resolution protocol request (ARP request) from an unauthenticated client terminal, the terminal to which the client terminal is connected Without the need for special features Can provide access control to a network that enables communication of the client terminal only provides the IP address from a Dynamic Host Configuration Protocol server to the client terminal that is user authentication in an environment that uses a specific Host Configuration Protocol.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a diagram for explaining the basic configuration and operation principle of a network system including an authentication DHCP server (authentication DHCP server computer) according to an embodiment of the present invention. In FIG. 1, an authentication DHCP server 1 and an authentication server 2 are connected to a network 3. The network 3 is an IP network, for example, and is used as a backbone LAN (local area network) of the network system. The network 3 is connected to a client (client terminal) 4 and another client (client terminal) 5 that is a communication partner of the client 4. In the system of FIG. 1, for convenience of drawing, two clients 4 and 5 are connected to the network 3, but generally three or more clients are connected to the network 3.

  The authentication DHCP server 1 functions as a network access control device that controls access to the network 3 so that an IP address can be provided only to a user (client) who has been user-authenticated in an environment using DHCP.

  The authentication server 2 is a general authentication server such as a RADIUS server (RADIUS server) corresponding to, for example, 802.1x defined by IEEE.

  The client 4 has a function as a DHCP client, and further has a function of an authentication client (for example, “Supplicant”) in authentication (for example, 802.1x authentication defined by IEEE). These functions are normally installed in a general-purpose OS (operating system) generally used as client software and do not require special client software.

Next, an outline of an operation related to network access control including IP address assignment centering on the authentication DHCP server 1 in the system of FIG. 1 will be described.
In the system of FIG. 1, it is assumed that the client 4 requests an IP address from the authentication DHCP server 1 by the DHCP protocol (step S1). Then, the authentication server interrupts the DHCP protocol with the client 4 and immediately transmits an authentication start request by the EAP protocol to the client 4 (step S2).

  The client 4 starts user authentication using the EAP protocol by the function “Supplicant” (step S3). Authentication by EAP is communication that does not use an IP header using EAPOL, so communication is possible even before an IP address is acquired. In step S3, the authentication DHCP server 1 relays authentication using EAPOL between the client 4 and the authentication server 2.

  When the authentication is completed, the authentication DHCP server 1 resumes the DHCP protocol with the suspended client 4 and distributes the IP address to the client 4 (step S4). Thereby, the client 4 acquires the IP address distributed from the authentication DHCP server 1, and communicates with, for example, the client 5 via the network 3 using the IP address (step S5).

  In the system of FIG. 1, the client 4 and the client 5 are connected to the same network 3 (that is, the network 3 having the same network address). However, the client 5 may be connected to another network having a network address different from that of the network 3, and the both networks may be connected by a router.

  In the system of FIG. 1, the authentication DHCP server 1 has a mechanism for preventing unauthorized terminals that are not authenticated from communicating (that is, a mechanism for preventing unauthorized terminals from connecting to the network 3). Hereinafter, this mechanism will be described with reference to FIG. Here, for convenience, it is assumed that the client 4 is an unauthorized terminal that is not authenticated (that is, an IP address is not distributed from the authenticated DHCP server 1).

  Now, an ARP (i.e., an ARP for acquiring a MAC address (that is, a physical address) of the other machine necessary for an unauthorized terminal (client 4) to communicate with another machine (for example, client 5) on the network 3. Assume that an Address Resolution Protocol request is broadcast on the network 3 (step S11). This ARP request includes a transmission source IP address and a transmission source MAC address.

  When the authentication DHCP server 1 receives the ARP request, the source IP address included in the ARP request is an IP address not distributed by itself (excluding the authentication server), or is included in the ARP request. Whether the client that transmitted the ARP request is an unauthorized terminal is determined based on whether the source MAC address is a MAC address other than the client that distributed the IP address (excluding the authentication server).

  If the source of the ARP request (client 4 in FIG. 2) is an unauthorized terminal, the authentication DHCP server 1 immediately uses a fake ARP to prevent the source (client 4) from connecting to the network 3. The response is transmitted to the transmission source (client 4) (step S12). This ARP response, that is, a fake ARP response to an ARP request from an unauthorized terminal (client 4) is all the IP addresses that the authentication DHCP server 1 has distributed as the MAC address of the machine (terminal) requested by the ARP request. The MAC address is different from any of the MAC addresses of the terminals. By such a false ARP response, the authentication DHCP server 1 prevents an unauthorized terminal (client 4) from communicating via the network 3. That is, the authentication DHCP server 1 makes a state in which an unauthorized terminal (client 4) cannot communicate by a fake ARP response.

  Next, in the system of FIG. 1, for example, with reference to the sequence chart of FIG. 3 and the format of communication data of FIGS. 4A to 4C for details of the communication sequence until the client 4 performs user authentication and acquires an IP address, for example. explain.

  The client 4 first includes data (specific packet) according to DHCP (Dynamic Host Configuration Protocol) called DHCP Discover, for example, for detecting a DHCP server (here, the authentication DHCP server 1) on the network 3. Then, the communication data 401 in the format shown in FIG. 4A (a) is transmitted by broadcast (step S21).

  The communication data 401 is a data link layer packet including a data link layer header. The payload of the data link layer packet (data link layer payload) includes an IP header, a UDP (User Datagram Protocol) header, and a UDP payload.

  The data link layer header of the communication data 401 includes a destination MAC address and a source MAC address. Here, the broadcast address is used as the destination MAC address, and the MAC address of the client 4 is used as the source MAC address. The IP header of the communication data 401 includes a destination IP address and a source IP address. Here, a broadcast address is used as the destination IP address, and a specific IP address (for example, an authentication DHCP server 1) used when detecting the DHCP server (here, the authentication DHCP server 1) according to DHCP (Dynamic Host Configuration Protocol) is used as the source IP address. "0.0.0.0") is used respectively. In the UDP payload of the communication data 401, “DHCP Discover” (data thereof) is set.

  When receiving the communication data 401 transmitted from the client 4, the authentication DHCP server 1 interrupts DHCP (Dynamic Host Configuration Protocol) with the client 4. Then, the authentication DHCP server 1 includes a special code called an EAP request (EAP Request) according to the extended authentication protocol to the client 4 that is the transmission source of the communication data 401 in order to start authentication, as shown in FIG. 4A (b). The communication data 402 in the format shown is transmitted (step S22).

  The communication data 402 is a data link layer packet including a data link layer header and an EAPOL packet (EAPOL frame). The EAPOL packet forms the payload of the data link layer packet, and the “EAP Request” is set in the data portion of the EAPOL packet. Here, nothing is stored in the data part of EAP (data part of the user authentication protocol).

  The data link layer header of the communication data 402 includes a destination MAC address and a source MAC address, similar to that of the communication data 401. Here, the source MAC address (the MAC address of the client 4) included in the data link layer header of the communication data 401 is used as the destination MAC address, as indicated by an arrow 403 in FIG. 4A (b). . Further, the MAC address of the authentication DHCP server 1 is used as the transmission source MAC address.

  When the client 4 receives the communication data 402 including the EAP request transmitted from the authentication DHCP server 1, the client 4 generates a special request called a RADIUS access request (Radius Access Request) storing the user ID for user authentication. To do. The client 4 then transmits the communication data 404 (first response) in the format shown in FIG. 4A (c) including the EAP response (EAP Response) in which the “Radius Access Request” is stored as data (that is, encapsulated by EAP). Authentication data).

Communication data 404 is a data link layer packet including a data link layer header and an EAPOL packet (EAPOL frame). “EAP Response” is set in the data part of the EAPOL packet, and the “Radius Access Request” is stored in the EAP data part (data part of the user authentication protocol). The destination MAC address of the data link layer header of the communication data 404 includes the source MAC address (included in the data link layer header of the received communication data 402 (see arrow 405 in FIG. 4A (b)). MAC address of the authentication DHCP server 1) is used. Further, the MAC address of the client 4 is used as the source MAC address.
The client 4 transmits the generated communication data 404 to the authentication DHCP server 1 (step S23). That is, the client 4 transmits “Radius Access Request” in which the user ID is stored to the authentication DHCP server 1 by “EAP Response”.

  When the authentication DHCP server 1 receives the communication data 404 transmitted from the client 4, as shown by an arrow 406 in FIG. 4A (d), the authentication DHCP server 1 stores the data portion of “EAP Response” included in the communication data 404. Retrieve stored "Radius Access Request". Then, the authentication DHCP server 1 generates communication data 407 (second authentication data) in the format shown in FIG. 4A (d) in which the extracted “Radius Access Request” is stored in the UDP payload. That is, the authentication DHCP server 1 converts the communication data 404 (first authentication data) transmitted from the client 4 into communication data 407 (second authentication data).

The communication data 407 includes a data link layer header, an IP header, a UDP header, and a UDP payload. The MAC address of the authentication server 2 and the MAC address of the authentication DHCP server 1 are used for the destination MAC address and the source MAC address of the data link layer header of the communication data 407, respectively. The IP address of the authentication server 2 and the IP address of the authentication DHCP server 1 are used as the destination IP address and the transmission source IP address of the IP header of the communication data 407, respectively. The UDP payload of the communication data 407 stores “Radius Access Request” extracted from the EAP data portion of the communication data 404.
The authentication DHCP server 1 transmits (relays) the generated (converted) communication data 407 to the authentication server 2 (step S24).

  When the authentication server 2 receives the communication data 407 including “Radius Access Request” relayed by the authentication DHCP server 1, the authentication server 2 includes data of an authentication protocol (user authentication protocol) called a Radius Access Challenge. Communication data 408 (third authentication data) in the format shown in 4B (a) is generated.

  “Radius Access Challenge” stores a challenge code for user authentication. This Challenge code is generated based on the user ID stored in “Radius Access Request” included in the received communication data 407. That is, the Challenge code is data corresponding to this user ID.

  The communication data 408 is a data link layer packet including a data link layer header, an IP header, a UDP header, and a UDP payload. The above-mentioned “Radius Access Challenge” is stored in the UDP payload.

  The MAC address and IP address of the authentication DHCP server 1 are used as the destination MAC address in the data link layer header of the communication data 408 and the destination IP address in the IP header, respectively. The authentication server 2 transmits this communication data 408 to the authentication DHCP server 1 (step S25).

  Upon receiving the communication data 408 transmitted from the authentication server 2, the authentication DHCP server 1 extracts “Radius Access Challenge” from the communication data 408 as indicated by an arrow 409 in FIG. 4B (a). Then, the authentication DHCP server 1 stores “Radius Access Challenge” extracted from the communication data 408 in the data part of “EAP Request” (that is, “Radius Access Challenge” is encapsulated with EAP), FIG. Communication data 410 (fourth authentication data) in the format shown in (a) is generated. That is, the authentication DHCP server 1 converts the communication data 408 (third authentication data) transmitted from the authentication server 2 into communication data 410 (fourth authentication data).

  The communication data 410 includes a data link layer header, and the MAC address of the client 4 is used as the destination MAC address of the header. The authentication DHCP server 1 transmits (relays) the communication data 410 to the client 4 (step S26).

  When the client 4 receives the communication data 410 including “EAP Request” transmitted from the authentication DHCP server 1, the client 4 is based on the Challenge code stored in the data part of the “EAP Request”, that is, “Radius Access Challenge”. To generate a response code. Then, the client 4 performs communication in the format shown in FIG. 4B (b) including “EAP Response” in which “Radius Access Request” including this response (Response) code is stored as data (that is, encapsulated by EAP). Data 411 (first authentication data) is generated.

  Similar to the communication data 404, the communication data 411 is a data link layer packet including a data link layer header and an EAPOL packet (EAPOL frame). “EAP Response” is set in the data part of the EAPOL packet, and “Radius Access Request” including the response code is stored in the EAP data part (data part of the user authentication protocol). The MAC address of the authentication DHCP server 1 is used as the destination MAC address in the data link layer header of the communication data 411.

  The client 4 transmits the generated communication data 411 to the authentication DHCP server 1 (step S27). That is, the client 4 transmits “Radius Access Request” in which a response code generated based on the Challenge code is stored to the authentication DHCP server 1 using “EAP Response”.

  When the authentication DHCP server 1 receives the communication data 411 (EAP Response) transmitted from the client 4, the “EAP Response” included in the communication data 411 is indicated by an arrow 412 in FIG. 4B (b). "Radius Access Request" stored in the data part of. Then, the authentication DHCP server 1 generates communication data 413 (second authentication data) having the format shown in FIG. 4B (b) in which the extracted “Radius Access Request” is stored in the UDP payload. That is, the authentication DHCP server 1 converts the communication data 411 (first authentication data) transmitted from the client 4 into communication data 413 (second authentication data).

  Similar to the communication data 407, the communication data 413 includes a data link layer header, an IP header, a UDP header, and a UDP payload. The MAC address and IP address of the authentication server 2 are used as the destination MAC address in the data link layer header of the communication data 413 and the destination IP address in the IP header, respectively. The UDP payload of the communication data 413 stores “Radius Access Request” extracted from the EAP data portion of the communication data 411. The authentication DHCP server 1 transmits (relays) the communication data 413 to the authentication server 2 (step S28).

  When the authentication server 2 receives the communication data 413 including the “Radius Access Request” transmitted from the authentication DHCP server 1, the authentication server 2 extracts a response code stored in the “Radius Access Request”. Then, the authentication server 2 checks whether the extracted Response code corresponds to the Challenge code transmitted for user authentication.

  If it is compatible, the authentication server 2 generates a Radius Access Accept for notifying that the authentication has been successful. Then, the authentication server 2 generates communication data 414 having the format shown in FIG. 4B (c) in which “Radius Access Accept” is stored in the UDP payload.

  The communication data 414 includes a data link layer header and an IP header. The MAC address and IP address of the authentication DHCP server 1 are used as the destination MAC address of the data link layer header and the destination IP address of the IP header, respectively. The authentication server 2 transmits this communication data 414 to the authentication DHCP server 1 (step S29).

  When the authentication DHCP server 1 receives the communication data 414 including “Radius Access Accept” transmitted from the authentication server 2, the authentication DHCP server 1 includes a special code called EAP Success for notifying that the authentication is successful. The communication data 415 in the format shown in FIG. 4C (a) is transmitted to the client 4 (step S30).

  The communication data 415 is a data link layer packet including a data link layer header and an EAPOL packet. The EAP success is set in the data part of the EAPOL packet. The MAC address of the client 4 is used as the destination MAC address of the data link layer header of the communication data 415.

  When the authentication DHCP server 1 transmits the communication data 415 including the EAP success (EAP Success) to the client 4, the authentication DHCP server 1 resumes the DHCP (dynamic host configuration protocol) with the suspended client 4. Then, the authentication DHCP server 1 includes a special packet (DHCP Offer packet) called DHCP offer (DHCP Offer packet) that declares that an IP address is distributed to a client that has been successfully authenticated, in the format shown in FIG. 4C (b). Communication data 416 is transmitted to the client 4 (step S31). The communication data 416 includes a data link layer header, an IP header, a UDP header, and a UDP payload. The MAC address and broadcast address of the client 4 are used as the destination MAC address in the data link layer header of the communication data 416 and the destination IP address in the IP header, respectively. The “DHCP Offer” (data) is stored in the UDP payload of the communication data 416.

  The authentication DHCP server 1 transmits the generated communication data 416 to the client 4 (step S31). That is, the authentication DHCP server 1 transmits “DHCP Offer” for distributing the IP address to the client that has been successfully authenticated, to the client 4.

  Upon receiving the communication data 416 (DHCP Offer) transmitted from the authentication DHCP server 1, the client 4 acquires an IP address in a standard sequence of DHCP (Dynamic Host Configuration Protocol) as described below.

  First, the client 4 generates communication data 417 in the format shown in FIG. 4C (c) including a special packet called a DHCP request (DHCP Request) for acquiring an IP address to be distributed to itself.

  The communication data 417 is a data link layer packet including a data link layer header, an IP header, a UDP header, and a UDP payload. The above-described “DHCP Request” (data) is stored in the UDP payload.

  As the destination MAC address and the source MAC address of the data link layer header of the communication data 417, the broadcast address and the MAC address of the client 4 are used, respectively. As the destination IP address and the source IP address of the IP header of the communication data 417, the broadcast address and the specific IP address (“0.0.0.0”) are used, respectively.

  The client 4 transmits the generated communication data 417 to the authentication DHCP server 1 (step S32). That is, the client 4 transmits “DHCP Request” to the authentication DHCP server 1.

  When the authentication DHCP server 1 receives the communication data 417 (DHCP Request) transmitted from the client 4 that has been successfully authenticated, the authentication DHCP server 1 is called DHCP approval (DHCP ACK) in which the IP address distributed to the client 4 is stored. Communication data 418 having a format shown in FIG. 4C (d) including a special packet (DHCP ACK packet) is generated. As the destination MAC address and the source MAC address of the data link layer header of the communication data 418, the MAC address of the client 4 and the MAC address of the authentication DHCP server 1 are used, respectively. The broadcast address and the IP address of the authentication DHCP server 1 are used for the destination IP address and the source IP address of the IP header of the communication data 418, respectively. The “DHCP ACK” (data thereof) is stored in the IP payload of the communication data 418. “DHCP ACK” includes an IP address distributed (assigned) to the client 4.

  The authentication DHCP server 1 transmits the generated communication data 418 to the client 4 (step S33). That is, the authentication DHCP server 1 distributes an IP address to the client 4 by transmitting “DHCP ACK” to the client 4 that has been successfully authenticated. The client 4 acquires the IP address by receiving the communication data 418 (DHCP ACK) transmitted from the authentication DHCP server 1. Thereafter, the client 4 is connected to the network 3 using this IP address, and can communicate with other clients (for example, the client 5) on the network 3.

  As described above, the authentication DHCP server 1 applied in the present embodiment interrupts DHCP (Dynamic Host Configuration Protocol) triggered by reception of a DHCP Discover packet broadcast from a client (here, the client 4). Authentication (proxy of authentication) is started, and after that, authentication using EAPLO is relayed, and an IP address is assigned to the authenticated client. Thus, if the client has a function as a DHCP client and a function of a supplicant (authentication client) in 802.1x authentication, the client can acquire an IP address without requiring a special function.

  Next, details of the communication sequence in which the authentication DHCP server 1 makes it impossible to communicate with an unauthorized terminal that has not distributed an IP address will be described with reference to the sequence chart of FIG. 5 and the format of communication data of FIG. . Here, unlike the case of FIG. 3, it is assumed that the client 4 is an unauthorized terminal to which no IP address is distributed from the authentication DHCP server 1.

  Now, it is assumed that the client 4 that is an unauthorized terminal needs to acquire the MAC address of the client 5 (communication partner) for communication with the client 5, for example. In this case, the client 4 broadcasts an ARP request 601 in the format shown in FIG. 6 for resolving the IP address of the client 5 (that is, the target) to a MAC address, on the network 3 (step S41).

  The ARP request 601 includes a data link layer header and an ARP request packet. As the destination MAC address and the source MAC address of the data link layer header, the broadcast address and the MAC address of the client 4 (illegal terminal) are used, respectively. The ARP request packet includes a target MAC address and a target IP address, and a transmission source MAC address and a transmission source IP address. The MAC address and IP address of the client 4 (illegal terminal) (IP address not distributed to the client 4 by the authentication DHCP server 1) are used for the source MAC address and source IP address of the ARP request packet.

  When receiving the ARP request 601 from the network 3, the authentication DHCP server 1 checks the transmission source IP address and the transmission source MAC address included in the ARP request packet of the ARP request 601. Then, the authentication DHCP server 1 determines whether the source IP address included in the ARP request packet is an IP address (excluding the authentication server) that is not distributed by itself, or the source MAC included in the ARP request. If the address is a MAC address other than the client that distributed the IP address (excluding the authentication server), the transmission source of the ARP request 601 (here, client 4) is determined to be an unauthorized terminal.

  Then, the authentication DHCP server 1 immediately sends a fake ARP response 602 in the format shown in FIG. 6 to the sender (client) in order to prevent the sender (here, the client 4) of the ARP request 601 from connecting to the network 3. 4) (step S42). A fake MAC address is used as the source MAC address of the fake ARP response 602. A fake MAC address refers to a nonexistent MAC address. Here, a MAC address in which a nonexistent value is used for the vendor ID corresponding to the upper 3 bytes of the MAC address is used as a fake MAC address.

  The unauthorized terminal (client 4) that has received the fake ARP response 602 from the authentication DHCP server 1 transmits communication data with the fake MAC address included in the ARP response 602 as the destination MAC address (step S43). ). In this case, an unauthorized terminal (client 4) cannot communicate because of a fake destination MAC address. That is, the authentication DHCP server 1 interrupts the communication of the unauthorized terminal (client) by returning a fake ARP response 602 in response to the ARP request 601 from the unauthorized terminal (client 4).

  FIG. 7 is a block diagram showing a configuration of the authentication DHCP server 1. The authentication DHCP server 1 includes an address management table 11, a table management unit 12, a network IF (network interface) 13, a packet processing unit 14, an ARP processing unit 15, an authentication processing unit 16, and a DHCP processing unit 17. including.

  FIG. 8 shows an example of the data structure of the address management table 11. The entry of the address management table 11 is used to store address information of a device such as a client under authentication, an authenticated client, the authentication server 2, or a router. The entry of the address management table 11 includes a MAC address field, an IP address, a status (status), an authenticator, an ID, and fields for holding an expiration date (MAC address field, IP address field, status field, authenticator field, ID Field and expiration date field). Hereinafter, each of the above fields will be described.

<MAC address field>
The MAC address field is used to hold the MAC address of a device such as a client under authentication, an authenticated client, the authentication server 2, or a router.

<IP address field>
The IP address field is used to hold the IP address of the device having the MAC address held in the MAC address field. In the case of an authenticating client, a predetermined IP address “0.0.0.0” is held in the IP address field. In the case of an authenticated client, the IP address assigned by the DHCP processing unit 17 is held in the IP address field.

<Status field>
The status field is used to hold the status of the device having the MAC address held in the MAC address field. It is assumed that there are two types of states, “authenticating” and “authenticated”. For example, in the case of a client, when the client transmits “DHCP Discover”, the status field is set to a status indicating “authenticating”. Thereafter, when the client completes the authentication and receives “Radius Access Accept” from the authentication server, the state field is switched to a state indicating “authenticated”. In the case of a device such as the authentication server 2 or a router, the status field is set to a status indicating “authenticated”.

<Authentication field>
The authenticator field is used to identify an authentication protocol session between the client and the authentication server 2 when the device having the MAC address held in the MAC address field is a client. The authenticator field holds the value of the authenticator field of a Radius packet used for authentication. In the case of a device such as the authentication server 2 or a router, for example, a predetermined value “0” is held in the authenticator field.

<ID field>
The ID field is used to identify a DHCP (Dynamic Host Configuration Protocol) session between the client and the authentication DHCP server 1 when the device having the MAC address held in the MAC address field is a client. . The ID field holds the value of the transaction ID field of the DHCP packet used in DHCP. In the case of a device such as the authentication server 2 or a router, for example, a predetermined value “0” is held in the ID field.

<Expiration date field>
The expiration date field is used to indicate the expiration date of information (address information) of an entry (corresponding entry) in the address management table 11 including the field. The value of this field is periodically decremented by the table management unit 12, and when the value becomes 0, the corresponding entry information is deleted from the address management table 11. The value of the expiration date field of the entry corresponding to the device such as the authentication server 2 or the router is held at, for example, a predetermined value −1 and is not subject to regular decrement. That is, the address information of the device such as the authentication server 2 or the router is statically registered in the address management table 11.

  Next, processing of the table management unit 12 in the authentication DHCP server 1 will be described with reference to the flowchart of FIG. The table management unit 12 periodically monitors the address management table 11. Here, it is assumed that the address management table 11 is monitored at intervals of 1 second, for example.

  First, the table management unit 12 extracts information on an unprocessed entry from the address management table 11 (step S51), and checks the value of the expiration date field in the entry (steps S52 and S53). If the value of the expiration date field is 0 (step S52), the table management unit 12 uses the address management table 11 to store information on the entry (corresponding entry) in the address management table 11 including the expiration date field. (Step S54).

  On the other hand, if the value of the expiration date field is −1 (step S53), the table management unit 12 statically registers the address information of the device such as the authentication server 2 or the router in the corresponding entry. It is determined that In this case, the table management unit 12 does not perform any operation on the corresponding entry. If the value of the expiration date field is neither 0 nor −1 (steps S52 and S53), the table management unit 12 decrements the value of the expiration date field by 1 (step S55).

  The table management unit 12 repeatedly executes the above processing for all entries in the address management table 11 (step S56), and ends the processing.

Next, processing of the network IF 13 in the authentication DHCP server 1 will be described with reference to the flowchart of FIG.
When receiving the communication data from the network 3, the network IF 13 transfers the communication data to the packet processing unit 14 in the table management unit 12 (step S60). Further, when communication data for transmission is input from any one of the ARP processing unit 15, the authentication processing unit 16, and the DHCP processing unit 17, the network IF 13 transmits the communication data to the network 3 (step S70). As described above, the network IF 13 transmits and receives communication data between the network 3 and the authentication DHCP server 1.

Next, the processing of the packet processing unit 14 in the authentication DHCP server 1 will be described with reference to the flowchart of FIG.
When the communication data received by the network IF 13 is transferred (input) to the packet processing unit 14, the packet processing unit 14 checks the type of the communication data (step S81). Here, it is checked whether the communication data is an ARP request, “DHCP Discover”, “EAP Response”, “Radius Access Challenge”, “Radius Access Accept”, “DHCP Request”, or otherwise (step S82). ~ S87).

When the input communication data is an ARP request (step S82), the packet processing unit 14 transfers the input communication data to the ARP processing unit 15 (step S88).
Next, when the input communication data is any one of “DHCP Discover”, “EAP Response”, and “Radius Access Challenge” (steps S83, S84, S85), the packet processing unit 14 authenticates the communication data. The data is transferred to the processing unit 16 (step S89).
When the input communication data is “Radius Access Accept” (step S86), the packet processing unit 14 transfers the communication data to both the authentication processing unit 16 and the DHCP processing unit 17 (steps S89 and S90).

  When the input communication data is “DHCP Request” (step S87), the packet processing unit 14 transfers the communication data to the DHCP processing unit 17 (step S90).

  If the input communication data is not one of the ARP request, “DHCP Discover”, “EAP Response”, “Radius Access Challenge”, “Radius Access Accept”, and “DHCP Request” (steps S82 to S87), packet processing The unit 14 does nothing and ends the process. That is, the packet processing unit 14 discards the input communication data.

Next, processing of the ARP processing unit 15 in the authentication DHCP server 1 will be described with reference to the flowchart of FIG.
First, it is assumed that the type of communication data is determined to be an ARP request, for example, an ARP request 601 having the format shown in FIG. 6 is input to the ARP processing unit 15 by the packet processing unit 14. Then, the ARP processing unit 15 has address information (the address information of the ARP request source) including the transmission source MAC address and the transmission source IP address of the ARP request 601 in the address management table 11, and the status field of the address information includes It is checked whether “authenticated” is indicated (step S91).

  If the address information of the ARP request source does not exist or does not exist but the status field of the address information does not indicate “authenticated” (step S92), the ARP processing unit 15 is shown in FIG. The process corresponding to step S12 is executed as follows. First, the ARP processing unit 15 generates a fake ARP response 602 having the format shown in FIG. 6 based on the ARP request 601 (step S93). Then, the ARP processing unit 15 transfers the generated fake ARP response 602 to the network IF 13 (step S94), and ends the process.

  On the other hand, if the address information of the ARP request source exists and the status field of the address information indicates “authenticated” (step S92), the ARP processing unit 15 determines that the target IP address of the ARP request 601 is Then, it is checked whether or not it matches the IP address of the authentication DHCP server 1 (step S95). This check is performed by comparing the target IP address of the ARP request 11 with the target IP address in the address information of the authentication DHCP server 1 registered in the address management table 11.

  If the target IP address of the ARP request 601 matches the IP address of the authentication DHCP server 1 (step S96), the ARP processing unit 15 responds to the ARP request 601 with an ARP response 131 in the format shown in FIG. Generate (step S97).

  The generated ARP response 131 includes a data link layer header and an ARP response packet. As the destination MAC address of the data link layer header of the ARP response 131, the source MAC address of the data link layer header of the ARP request 601 is used, as indicated by the arrow 132 in FIG. Further, the target MAC address and the target IP address of the ARP response packet of the ARP response 131 are respectively the source MAC address and the source of the ARP request packet of the ARP request 601 as indicated by arrows 133 and 134 in FIG. An IP address is used. Further, the MAC address and IP address of the authentication DHCP server 1 are used as the source MAC address and source IP address of the ARP response 131, respectively.

  When the ARP processing unit 15 generates the ARP response 131 (step S97), the process proceeds to step S94. In step S94, the ARP processing unit 15 transfers the generated ARP response 131 to the network IF 13, and ends the process.

  On the other hand, if the target IP address of the ARP request 601 does not match the IP address of the authentication DHCP server 1 (step S96), the ARP processing unit 15 ends the process without doing anything.

Next, processing of the authentication processing unit 16 in the authentication DHCP server 1 will be described with reference to the flowchart of FIG.
First, it is assumed that communication data is input to the authentication processing unit 16 by the packet processing unit 14. Then, the authentication processing unit 16 functions as a communication data type determination unit, and checks the type of communication data (step S101). Here, it is checked whether the communication data is “DHCP Discover”, “EAP Response”, “Radius Access Challenge”, “Radius Access Accept”, or otherwise (steps S102 to S105).

  If the input communication data is, for example, the communication data 401 shown in FIG. 4A (a), and it is determined that the type of the data 401 is “DHCP Discover” (step S102), the authentication processing unit 16 The address information 150 shown in FIG. 15 is generated, and the address information is stored in the empty entry of the address management table 11 (step S106). In the MAC address field and the IP address field of the address information 150, the transmission source MAC address of the communication data 401 and the predetermined IP address “0.0.0.0” are held, respectively. In the state field, the authenticator field, and the ID field of the address information 150, a state indicating “authenticating”, and a transaction ID of a predetermined value “0” and “DHCP Discover” are held, respectively. In the expiration date field of the address information 150, an initial value of the expiration date, for example, a value representing 300 seconds is held. In this case, if the authentication is not completed within 300 seconds, the address information 150 is deleted from the address management table 11. The initial value of the expiration date may be set to an arbitrary value by the operation of the administrator of the authentication DHCP server 1.

  The authentication process part 16 will start an authentication process, if step S106 is performed. That is, the authentication processing unit 16 generates communication data 402 (EAP request) shown in FIG. 4A (b) addressed to the MAC address of the transmission source of “DHCP Discover” including “EAP Request” based on the communication data 401 ( Step S107). And the authentication process part 16 transfers the produced | generated communication data 402 (EAP request) to network IF13 (step S108), and complete | finishes a process.

  Next, when the input communication data is, for example, the communication data 404 shown in FIG. 4A (c), and therefore it is determined that the type of the data is “EAP Response” (step S103), the authentication processing unit 16 refers to the address management table 11 (step S109). In step S <b> 109, the authentication processing unit 16 searches for address information including a MAC address that matches the transmission source MAC address of the communication data 404. In step S109, the authentication processing unit 16 further sets (copies) the value of the authenticator field of “Radius Access Request” stored in the data part of “EAP Response” in the authenticator field of the searched address information. . That is, the authentication processing unit 16 updates the value of the authenticator field of the searched address information to the value of the authenticator field of “Radius Access Request” stored in the data part of “EAP Response”. An example of the updated address information is shown in FIG.

  Next, the authentication processing unit 16 functions as a relay unit (conversion unit), and based on the communication data 404 including “EAP Response”, the “Radius Access” stored (encapsulated) in the data unit of the “EAP Response” Communication data 407 (Radius access request) addressed to the authentication server 2 in the format shown in FIG. 4A (d) in which “Request” is stored (copied) in the UDP payload is generated (step S110). Then, in order to relay the generated (converted) communication data 407 (Radius access request) to the authentication server 2, the authentication processing unit 16 transfers the communication data 407 to the network IF 13 (step S108) and ends the processing. To do.

  Next, when the input communication data is, for example, the communication data 408 shown in FIG. 4B (a), and it is determined that the type of the data is “Radius Access Challenge” (step S104), the authentication process The unit 16 refers to the address management table 11 (step S111). In step S <b> 111, the authentication processing unit 16 searches for address information including an authenticator that matches the value of the authenticator field of “Radius Access Challenge” included in the communication data 408.

  Next, the authentication processing unit 16 functions as a relay unit (conversion unit), and sets the MAC address of the retrieved address information as the destination MAC address, and the “Radius Access Challenge” of the communication data 408 is changed to the data unit of “EAP Request”. The stored (encapsulated) communication data 410 (EAP request) in the format shown in FIG. 4B (a) is generated (step S112). Then, the authentication processing unit 16 transfers the generated communication data 410 (EAP request) to the network IF 13 in order to relay the generated communication data 410 (EAP request) to the client (client 4 in this case) indicated by the destination MAC address. (Step S108), and the process ends.

  Next, when the input communication data is, for example, the communication data 414 shown in FIG. 4B (c), and it is determined that the type of the data is “Radius Access Accept” (step S105), the authentication process The unit 16 refers to the address management table 11 (step S113). In step S <b> 113, the authentication processing unit 16 searches for address information including an authenticator that matches the value of the authenticator field of “Radius Access Accept” included in the communication data 414. In step S113, the authentication processing unit 16 further changes the state field of the searched address information from a state indicating “authenticating” to a state indicating “authenticated”. An example of the address information after the change is shown in FIG.

  Next, the authentication processing unit 16 functions as a relay unit (conversion unit), and the MAC address of the searched address information is set as the destination MAC address, and EAP success (EAP Success) is stored in the data part of the EAPOL packet. Communication data 415 in the format shown in 4C (a) is generated (step S114). Then, the authentication processing unit 16 transfers the communication data 415 to the network IF 13 in order to relay the generated (converted) communication data 415 (EA success) to the client (client 4 in this case) indicated by the destination MAC address. (Step S108), and the process ends.

  Next, when the input communication data is not any of “DHCP Discover”, “EAP Response”, “Radius Access Challenge”, and “Radius Access Accept” (steps S102 to S105), the authentication processing unit 16 does nothing. The process ends without doing. That is, the authentication processing unit 16 discards the input communication data.

Next, the processing of the DHCP processing unit 17 in the authentication DHCP server 1 will be described with reference to the flowchart of FIG.
First, it is assumed that communication data is input to the DHCP processing unit 17 by the packet processing unit 14. Then, the DHCP processing unit 17 checks the type of communication data (step S121). Here, it is checked whether the communication data is “Radius Access Accept”, “DHCP Request”, or other (Steps S122 and S123).

  When the input communication data is, for example, the communication data 414 shown in FIG. 4B (c), and it is determined that the type of the data 414 is “Radius Access Accept” (step S122), the DHCP processing unit 17 Refers to the address management table 11 (step S124). In step S124, the DHCP processing unit 17 includes a MAC address and an authenticator that respectively match the transmission source MAC address of the communication data 414 and the value of the “Radius Access Accept” authenticator field included in the communication data 414. Check whether the target address information exists.

  If the target address information does not exist (step S125), the DHCP processing unit 17 does nothing and ends the process. That is, the DHCP processing unit 17 discards the input communication data.

  On the other hand, if the target address information exists (step S125), the DHCP processing unit 17 functions as an IP address assigning unit, and newly assignable IP addresses that are not used in the address management table 11 are selected. Determination is made (step S126). Then, the DHCP processing unit 17 sets the IP address determined in step S126 in the IP address field of the target address information in the address management table 11 (step S127). An example of the address information after setting the IP address is shown in FIG.

  Next, the DHCP processing unit 17 performs communication data 416 (DHCP Offer packet) shown in FIG. 4C (b) in which “DHCP Offer” is stored in the UDP payload based on the address information after the IP address setting shown in FIG. ) Is generated (step S128). As the destination MAC address of the communication data 415, the MAC address included in the address information after setting the IP address is used.

FIG. 20 shows a detailed format of the generated communication data 416. As shown in FIG. 20, “DHCP Offer” included in the communication data 416 includes a transaction ID, a user IP address, and a client MAC address. For the “DHCP Offer” transaction ID, user IP address, and client MAC address, the value of the ID field, the IP address (determined IP address), and the MAC address included in the address information shown in FIG. 19 are used. .
The DHCP processing unit 17 transfers the generated communication data 416 (DHCP Offer) to the network IF 13 (step S129), and ends the process.

  On the other hand, if the input communication data is, for example, the communication data 417 shown in FIG. 4C (c), and it is determined that the type of the data 417 is “DHCP Request” (step S123), the DHCP processing unit 17 refers to the address management table 11 (step S130). In step S130, the DHCP processing unit 17 determines whether there is target address information including a MAC address and an ID that match the transmission source MAC address of the communication data 417 and the transaction ID value included in the communication data 417, respectively. Check.

  If the target address information does not exist (step S131), the DHCP processing unit 17 does nothing and ends the process. That is, the DHCP processing unit 17 discards the input communication data.

  On the other hand, if the target address information exists in the address management table 11 (step S131), the DHCP processing unit 17 functions as an IP address assigning means, and the address information contains the address information in the expiration date field. A value indicating the expiration date (lease time limit) of the IP address set in the IP address field is set (step S132). Here, as the lease time limit, a value indicating a time limit longer than the valid time limit “300 seconds” during authentication, for example, 200000 seconds, is set. An example of the address information after setting the lease term is shown in FIG.

  Next, the DHCP processing unit 17 is shown in FIG. 4C (d), in which DHCP approval (DHCP ACK) is stored in the UDP payload based on the address information (see FIG. 21) in which the lease term of the IP address is set. Communication data 418 (DHCP ACK packet) is generated (step S133). As the destination MAC address of the communication data 418, the MAC address included in the address information in which the lease time limit is set is used.

FIG. 22 shows a detailed format of the generated communication data 418. As shown in FIG. 22, the DHCP ACK packet included in the communication data 418 includes a transaction ID, a user IP address, and a client MAC address. As the transaction ID, user IP address, and client MAC address of the DHCP ACK packet, the value of the ID field, the IP address, and the MAC address included in the address information shown in FIG. 21 are used.
The DHCP processing unit 17 transfers the generated communication data 418 (DHCP ACK packet) to the network IF 13 (step S129), and ends the process.

  As described above, in the present embodiment, the authentication DHCP server 1 is provided with the address management table 11, and the address management table 11 associates with the physical address of the client and is used for communication according to the authentication state of the client and the authentication protocol. An authenticator (identification information) for identifying a session to be managed is managed. Thereby, authentication of a plurality of clients including the client 4 can be executed in parallel.

  In this embodiment, the address management table 11 identifies not only the authentication status of the client but also a transaction (session) used in DHCP (Dynamic Host Configuration Protocol) in association with the physical address of the client. Identification information (transaction ID) is managed. Thereby, a plurality of clients including the client 4 can execute IP address acquisition by DHCP in parallel.

[Modification]
Next, a modification of the above embodiment will be described.
In the above-described embodiment, the authentication DHCP server 1 transmits a fake ARP response (ARP response packet) to the unauthorized client so that the unauthorized client (that is, an unauthenticated client) cannot communicate. In addition to this, the feature of this modification is a fake to prevent transmission of communication data to the unauthorized client even for the client specified by the target IP address of the ARP request from the unauthorized client. The authentication DHCP server 1 transmits the ARP packet.

  Hereinafter, a modified example of the mechanism applied in the above embodiment shown in FIG. 2 will be described with reference to FIG. In FIG. 23, the same parts as those in FIG. In FIG. 23, as in FIG. 2, it is assumed that the client 4 is an unauthorized terminal that is not authenticated.

  First, it is assumed that the client 4 which is an unauthorized terminal broadcasts an ARP request for acquiring the MAC address of the client 5 necessary for communicating with the client 5, for example, on the network 3 (step S11). . Assume that the authentication DHCP server 1 receives an ARP request from the client 4 and determines that the transmission source (client 4) of the ARP request is an unauthorized terminal, as in the above embodiment.

  Then, the authentication DHCP server 1 immediately transmits a fake ARP response to the transmission source in order to disturb the communication of the transmission source (the unauthorized client 4) of the ARP request (step S12). In addition to this, the authentication DHCP server 1 also transmits communication data to the transmission source (the unauthorized client 4) of the ARP request to the client (here, the client 5) specified by the target IP address of the ARP request. A fake ARP packet for preventing the transmission, for example, a fake Gratuitous ARP (G-ARP) packet is transmitted (step S13). The G-ARP packet is a special address resolution protocol packet for confirming the conflict of the target IP address. The processes in steps S12 and S13 performed by the authentication DHCP server 1 are performed by the ARP processing unit 15 in the authentication DHCP server 1.

  Hereinafter, the processing of the ARP processing unit 15 in the modification of the above embodiment will be described with reference to the flowchart of FIG. 24, focusing on differences from the above embodiment. In addition, the same code | symbol is attached | subjected to the step similar to the flowchart of FIG.

  The ARP processing unit 15 that has received the ARP request 601 shown in FIG. 6 from the client 4 executes steps S91 and S92 in the same manner as in the above embodiment, thereby transmitting the ARP request 601 from the source (client 4). Is determined to be an unauthorized client. In this case, the ARP processing unit 15 generates a fake ARP response 602 having the format shown in FIG. 6 based on the ARP request 601 (step S93).

  Next, the ARP processing unit 15 refers to the address management table 11 and checks whether address information (target address information) including an IP address that matches the target IP address of the ARP request 601 exists in the address management table 11. (Step S131). If the target address information exists (step S132), the ARP processing unit 15 proceeds to step S133. In step S133, the ARP processing unit 15 prevents the client (client 5) specified by the target IP address of the ARP request 601 from transmitting communication data to the transmission source (client 4) of the ARP request 601. Based on the ARP request 601, a fake G-ARP (Gratuitous ARP) 251 having the format shown in FIG.

  The fake G-ARP 251 includes a data link layer header and an ARP response packet. Similar to the fake ARP response 602 (see FIG. 6), a fake MAC address is used for the data link layer header of the fake G-ARP 251 and the source MAC address of the ARP response packet. The destination MAC address of the data link layer header of the fake G-ARP 251 includes the MAC address included in the target address information, that is, the MAC of the client (client 5) specified by the target IP address of the ARP request 601. An address is used. As shown by arrows 252 and 253 in FIG. 25, the source IP address of the ARP request 601 (that is, the unauthorized client 4) is included in the target IP address and the source IP address of the ARP response packet of the fake G-ARP 251. IP address) is used.

  Next, the ARP processing unit 15 transfers the fake ARP response 602 generated in step S93 and the fake G-ARP 251 generated in step S133 to the network IF 13 (step S94), and ends the process.

  The network IF 13 transmits the fake ARP response 602 and the fake G-ARP 251 to the network 3 (step S70 in FIG. 10A). The unauthorized client 4 transmits communication data addressed to a fake MAC address in accordance with a fake ARP response 602. Thereby, it is possible to prevent an unauthorized client 4 from communicating with the client 5.

  On the other hand, the client 5 rewrites the MAC address of the unauthorized client 4 in the address management table managed by the client 5 to a fake MAC address in accordance with the fake G-ARP 251. Thereby, even if the client 5 transmits the communication data addressed to the fake MAC address, the unauthorized client 4 cannot receive the communication data. That is, communication data can be prevented from being transmitted to the unauthorized client 4 to the client 5 specified by the target IP address of the ARP request 601 from the unauthorized client 4.

  On the other hand, if the target address information does not exist (step S132), the ARP processing unit 15 skips step S133 and proceeds to step S94, assuming that it is not necessary to generate a fake G-ARP. In this case, as in the above embodiment, the ARP processing unit 15 transfers the fake ARP response 602 generated in step S93 to the network IF 13 and ends the process.

  In addition, this invention is not limited to the said embodiment or its modification example as it is, A component can be deform | transformed and embodied in the range which does not deviate from the summary in an implementation stage. In addition, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the embodiment or its modification. For example, you may delete a some component from all the components shown by embodiment or its modification.

The figure for demonstrating the basic composition and operation | movement principle of a network system containing the authentication DHCP server which concerns on one Embodiment of this invention. The figure for demonstrating the structure for making the unauthorized terminal which is not authenticated into the state which cannot communicate in the system shown by FIG. The sequence chart which shows the detail of a communication sequence until a client authenticates a user and acquires an IP address in the system of FIG. The figure which shows the format of the communication data applied with the said communication sequence. The figure which shows the format of the communication data applied with the said communication sequence. The figure which shows the format of the communication data applied with the said communication sequence. The sequence chart which shows the detail of the communication sequence which makes a state which cannot communicate an unauthorized terminal. The figure which shows the format of the communication data applied with the communication sequence of FIG. The block diagram which shows the structure of the authentication DHCP server shown by FIG. The figure which shows the example of a data structure of the address management table shown by FIG. The flowchart which shows the process sequence of the table management part in an authentication DHCP server. The flowchart which shows the process sequence of network IF in an authentication DHCP server. The flowchart which shows the process sequence of the packet process part in an authentication DHCP server. The flowchart which shows the process sequence of the ARP process part in an authentication DHCP server. The figure which shows the format of an ARP request | requirement and an ARP response. The flowchart which shows the process sequence of the authentication process part in an authentication DHCP server. The figure which shows an example of address information. The figure which shows an example of address information. The figure which shows an example of address information. The flowchart which shows the process sequence of the DHCP process part in an authentication DHCP server. The figure which shows an example of address information. The figure which shows the format of the communication data containing a DHCP Offer packet. The figure which shows an example of address information. The figure which shows the format of the communication data containing a DHCP ACK packet. The figure which shows the modification of the mechanism applied in the said embodiment shown by FIG. The flowchart which shows the process sequence of the ARP process part in the modification of the said embodiment. The figure which shows the format of an ARP request | requirement and G-ARP.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Authentication DHCP server, 2 ... Authentication server, 3 ... Network, 4, 5 ... Client (client terminal), 11 ... Address management table, 12 ... Table management part, 13 ... Network IF, 14 ... Packet processing part, 15 ... ARP processing unit, 16 ... authentication processing unit, 17 ... DHCP processing unit.

Claims (6)

In a dynamic host configuration protocol server that assigns an IP address to a client terminal connected to a network,
A management table that holds the authentication status of the client terminal in association with the physical address of the client terminal connected to the network;
A network interface for transmitting and receiving communication data to and from the network;
Relay means for relaying authentication data sent from a client terminal unassigned to an IP address connected to the network for requesting authentication to an authentication server connected to the network via the network interface;
When the authentication server notifies that the authentication requested from the client terminal has been successful, the authentication state held in the management table in association with the physical address of the client terminal that requested the authentication, An authentication processing means for setting to a state indicating authenticated;
IP address assigning means for assigning an IP address to a client terminal having a physical address held in the management table in association with the authentication state set in the state indicating the authenticated state;
When an address resolution protocol request transmitted by broadcast from a client terminal connected to the network is received by the network interface, the client terminal that has transmitted the address resolution protocol request with reference to the management table Address resolution protocol processing means for determining whether or not the address resolution protocol has been authenticated, and transmitting a fake address resolution protocol response to the client terminal that has transmitted the address resolution protocol request via the network interface if the authentication has not been completed. A dynamic host configuration protocol server. The authentication processing means receives communication data including a specific packet for detecting a dynamic host configuration protocol server according to a dynamic host configuration protocol, which is transmitted by broadcast from a client terminal connected to the network, by the network interface. An extended authentication protocol request for generating an authentication according to the extended authentication protocol, and transmitting the generated request to the client terminal that is the transmission source of the specific packet via the network interface. Including request generation means,
The relay means includes conversion means,
In the case where the authentication data is first authentication data encapsulated by an extended authentication protocol transmitted from the client terminal in response to the extended authentication protocol request, the conversion means converts the first authentication data into the first authentication data. The second authentication data is converted into second authentication data including an IP header addressed to the authentication server, and the second authentication data is transmitted to the authentication server via the network interface, and the authentication server according to the second authentication data. When the third authentication data is transmitted from the third authentication data, the third authentication data is converted into fourth authentication data encapsulated by the extended authentication protocol, and the fourth authentication data is converted into the first authentication data. The dynamic data according to claim 1, wherein the authentication data is transmitted to the client terminal that is a transmission source of the authentication data via the network interface. Host configuration protocol server. Each communication data of the extended authentication protocol request, the first authentication data, the second authentication data, the third authentication data, and the fourth authentication data is transmitted to the client terminal to which the communication data is transmitted. An authenticator for identifying a session used in communication with the authentication protocol with the dynamic host configuration protocol server;
The management table is associated with the physical address of the client terminal connected to the network, and in addition to the authentication state of the client terminal, according to the authentication protocol between the client terminal and the dynamic host configuration protocol server Holds identification information to identify the session used in communication,
The conversion means converts the authentication data to be converted at the time of conversion from the first authentication data to the second authentication data and at the time of conversion from the third authentication data to the fourth authentication data. 3. The operation according to claim 2, wherein a physical address held in the management table in association with identification information matching the identification information included is determined as a destination physical address of authentication data after conversion. Host configuration protocol server. The specific packet includes a transaction ID for identifying a transaction used in the dynamic host configuration protocol,
The management table is associated with the physical address of the client terminal connected to the network, and in addition to the authentication state of the client terminal, the dynamic host between the client terminal and the dynamic host configuration protocol server Holds the transaction ID for identifying the transaction used in communication by the configuration protocol,
When the communication data including the specific packet is received by the network interface, the authentication processing means is associated with the physical address of the client client terminal that has transmitted the communication data, and indicates an authentication state indicating that authentication is in progress Setting the transaction ID included in the specific packet of communication data in the management table;
The IP address allocating unit includes the IP address to be allocated to the client terminal and the transaction ID stored in the management table in association with the physical address of the client terminal and having the physical address as a destination. The dynamic host configuration protocol server according to claim 2, wherein a packet conforming to a dynamic host configuration protocol is generated, and the generated packet is transmitted to the client terminal via the network interface. When the authentication state of the client terminal associated with the physical address of the client terminal connected to the network indicates authenticated, the management table indicates the authenticated in association with the physical address In addition to the authentication status, the IP address assigned to the client terminal is held,
The address resolution protocol request includes a target IP address to be resolved;
The address resolution protocol processing means transmits the fake address resolution protocol response to the client terminal that has transmitted the address resolution protocol request via the network interface, and also includes a special address for confirming the conflict of the target IP address. Sending an address resolution protocol request to a client terminal having a physical address held in the management table in association with an IP address matching the target IP address included in the address resolution protocol request via the network interface; The dynamic host configuration protocol server according to claim 1. In an IP address assignment method for a dynamic host configuration protocol server to assign an IP address to a client terminal connected to a network,
Authentication data sent to the dynamic host configuration protocol server sent from the client terminal not assigned an IP address connected to the network to request authentication is sent to the authentication server connected to the network. The protocol server relays,
As a result of the authentication server succeeding in the authentication based on the authentication data relayed to the authentication server by the dynamic host configuration protocol server, authentication data indicating that the authentication requested from the client terminal has been successful is the authentication server. When the dynamic host configuration protocol server is notified by the dynamic host configuration protocol server, the management table of the dynamic host configuration protocol server indicates that the dynamic host configuration protocol server is authenticated in association with the physical address of the client terminal. Setting an authentication state to indicate;
The dynamic host configuration protocol server assigns an IP address to a client terminal of a physical address held in the management table in association with an authentication state set to a state indicating the authenticated;
When an address resolution protocol request transmitted by broadcast from a client terminal connected to the network is received by the network interface, the dynamic host configuration protocol server refers to the management table, and Determining whether the client terminal that sent the address resolution protocol request has been authenticated;
The dynamic host configuration protocol server transmits a fake address resolution protocol response to the client terminal that has transmitted the address resolution protocol request when it is determined that it has not been authenticated. Assignment method.

Images