 |
Description  |
|
|
RELATED APPLICATIONS
The following co-pending patent applications, which were filed on Dec. 9,
1996, are related to the subject application and are herein incorporated
by reference:
1. Application Ser. No. 08/763,234, entitled "Method and Apparatus for
Client-Sensitive Name Resolution Using DNS" of Swee Boon Lim, Sanjay R.
Radia, and Thomas Wong and Michael W. Patrick.
2. Application Ser. No. 08/762,393, entitled "Method and Apparatus for
Access Control in a Distributed Multiserver Network Environment" of Thomas
Wong, Sanjay R. Radia, Swee Boon Lim, Panagiotis Tsirigotis, and Rob
Goedman.
3. Application Ser. No. 08/762,402, entitled "Method and Apparatus for
Dynamic Packet Filter Assignments" of Sanjay R. Radia, Swee Boon Lim,
Panagiotis Tsirigotis, Thomas Wong, and Rob Goedman.
4. Application Ser. No. 08/763,289, entitled "Load Balancing and Failover
of Network Services" of Swee Boon Lim, Ashish Singhai, and Sanjay R.
Radia.
5. Application Ser. No. 08/763,212, entitled "A Method to Activate
Unregistered Systems in a Distributed Multiserver Network Environment" of
Thomas Wong and Sanjay R. Radia.
6. Application Ser. No. 08/762,709, entitled "A Method and Apparatus for
Assignment of IP Addresses" of Thomas Wong, Swee Boon Lim, Sanjay R.
Radia, Panagiotis Tsirigotis, and Rob Goedman and Michael W. Patrick.
7. Application Ser. No. 08/762,933, entitled "A Method for Using DHCP to
Override Learned IP Addresses in a Network" of Sanjay R. Radia, Thomas
Wong, Swee Boon Lim, Panagiotis Tsirigotis, Rob Goedman, and Mike Patrick.
8. Application Ser. No. 08/762,705, entitled "Dynamic Cache Preloading
Across Loosely Coupled Administrative Domains" of Panagiotis Tsirigotis
and Sanjay R. Radia.
The following co-pending patent application is related to the subject
application and is herein incorporated by reference:
9. U.S. Application Ser. No. 08/673,951, filed Jul. 1, 1996, entitled "A
Name Service for a Redundant Array of Internet Servers" of Swee Boon Lim.
FIELD OF THE INVENTION
The present invention relates generally to security in computer networks.
More specifically, the present invention is a method and apparatus for
reducing the probability of IP address misuse among the clients of a DHCP
server.
BACKGROUND OF THE INVENTION
Computer networks that use the Internet protocol are commonly referred to
as "IP networks." Within IP networks, host systems and other objects are
identified by thirty-two bit numbers, known as Internet Protocol Addresses
(IP addresses). IP addresses provide a simple mechanism for identifying
the source and destination of messages sent within IP networks.
Increasingly, IP addresses within IP networks are assigned using the
Dynamic Host Configuration Protocol (DHCP) defined in Internet RFC 1541
which is incorporated herein by reference. In networks that use the DHCP
protocol, client systems request IP addresses from a DHCP server. The DHCP
server allocates an IP address for use by the requesting client system and
sends the client a message telling the client system which IP address to
use.
The IP address allocated by the DHCP server is "leased" to the client
system for a fixed period of time. Subsequently, the client system is
responsible for periodically renewing the lease of the IP address. The
client system and the DHCP server use an object known as a lease
identification cookie to identify the client's lease. The client system
may choose the lease identification cookie by sending the DHCP server a
client identifier. Alternatively, the DHCP server uses the client system's
IEEE-style MAC address as the lease identification cookie. The client
system periodically renews its lease by sending a lease renewal message to
the DHCP server that includes the lease identification cookie.
Unfortunately, allocation of IP addresses using traditional DHCP servers is
subject to several possible attacks. One such attack is known commonly as
"IP address hijacking." IP address hijacking occurs when a first client
system acquires the IP address of a second client system. The first client
maintains the hijacked IP address by sending lease renewal messages to the
DHCP server using the second client system's lease identification cookie.
In fact, since host names are commonly used as lease identification
cookies, it is even possible for this type of attack to happen
inadvertently. IP address hijacking confuses the network since a single IP
address is now used by more than one host. As a result, network
performance is degraded.
A second type of attack is known as "IP address hogging." For an attack of
this type, a client system attempts to exhaust the supply of IP addresses
by repeatedly obtaining IP leases from the DHCP server. Once the client
system has leased all of the available IP address leases, network
performance degrades as legitimate users are forced to wait for IP
addresses.
Based on the foregoing, it may be appreciated that there is a need for DHCP
servers that discourage both IP address hijacking and IP address hogging.
SUMMARY OF THE INVENTION
A preferred embodiment of the present invention includes a method and
apparatus for allocation of IP addresses that discourages IP address
misuse. More specifically, a preferred environment for the present
invention is a computer network that includes a series of client systems.
Each client system is connected to a corresponding cable modem that is
connected, in turn, to a router. The router forwards packets between the
client systems and one or more server systems. The network includes one or
more DHCP server systems that provide for allocation of IP addresses in
accordance with the Dynamic Host Configuration Protocol (DHCP) defined in
Internet RFC 1541.
The network also includes a secure DHCP relay agent that forwards DHCP
messages between the client systems and the DHCP servers. In some cases,
the secure DHCP relay agent will be included in the router. In other
cases, it may be preferably to include the secure DHCP relay agent as a
separate network component. The secure DHCP relay agent monitors IP
packets within the network and detects DHCP broadcast messages. When a
DHCP broadcast message is detected, the secure DHCP relay agent encodes a
"trusted identifier" within the vendor-specific information of the DHCP
broadcast message. The trusted identifier is an unforgeable value that is
associated with the source of the DHCP broadcast message. In a preferred
embodiment of the present invention, the trusted identifier is the modem
id of the cable modem that connects the client system sending the DHCP
broadcast message to the router.
Within the network, the cable modems and the cable router act as a secure
IP relay agent. Working with the secure DHCP relay agent, the secure IP
relay agent monitors allocation of IP addresses by the DHCP server to the
client systems. After allocation of an IP address to a client system, the
secure IP relay agent discards all IP packets originating from the client
system that do not include the assigned IP address. In this fashion, the
secure IP relay agent prevents the client systems from sending IP packets
with forged source addresses.
As used in a preferred embodiment of the present invention, the DHCP server
includes a lease database having a lease identifier index and an IP
address index. Each entry in the lease identifier index is a combination
of a lease identification cookie and a trusted identifier. Each entry in
the IP address index is an IP address. Each record in the lease database
is an IP address lease. The DHCP server also includes a trusted identifier
database. The trusted identifier database has a single index with each
entry in the index being a trusted identifier. Each record in the trusted
identifier database is one or more IP address leases.
Broadcast DHCP messages that reach the DHCP server pass first through the
secure DHCP relay agent. The broadcast DHCP messages are then unicast to
the DHCP server. As a result of passing through the DHCP relay agent, each
DHCP message reaching the DHCP server includes the trusted identifier
embedded by the secure DHCP relay agent. When the DHCP server receives a
DHCP message, it first examines the message to determine if it is a
message type that requires access to an existing IP address lease. If so,
the DHCP server extracts the trusted identifier and lease identification
cookie included in the message. The trusted identifier and lease
identification cookie are then combined to retrieve the existing lease
from the lease database (using the lease identifier index of the lease
database). In this way, a client system is prevented from accessing IP
address leases that are not associated with the client system's trusted
identifier. In particular, client systems may only renew their own leases.
Before a lease is granted, the DHCP server uses the trusted identifier to
query the trusted identifier database. If the trusted identifier database
includes a record corresponding to the trusted identifier, the record is
retrieved. Alternatively, if the trusted identifier database does not
include a record corresponding to the trusted identifier then the DHCP
server creates a new record. The new record includes no IP address leases.
Using the retrieved or new record, the DHCP server tabulates the number of
IP address leases assigned to the trusted identifier. If this number
exceeds a preset limit, the DHCP server does not grant the requested IP
address lease. In this way, the DHCP server prevents a single client
system from obtaining an inordinate number of IP address leases. If an IP
address lease is granted, the DHCP server adds the new lease to the record
corresponding to the trusted identifier.
Unicast DHCP messages that reach the DHCP server do not pass through the
secure DHCP relay agent. As a result, the trusted identifier is not
included in unicast DHCP messages. When the DHCP server receives a message
of this type, it extracts the source address included in the message (the
source address is actually extracted from the IP packet or packets that
comprise the IP message). The extracted source IP address is then used to
retrieve the IP address lease in question from the lease database (using
the IP address index of the lease database). Since the secure IP relay
agent ensures unforgeability of the source address of the unicast DHCP
message, a client system is prevented from accessing the IP address leases
of other client systems. In particular, client systems may only renew
their own leases.
Advantages of the invention will be set forth, in part, in the description
that follows and, in part, will be understood by those skilled in the art
from the description or may be learned by practice of the invention. The
advantages of the invention will be realized and attained by means of the
elements and combinations particularly pointed out in the appended claims
and equivalents.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part
of this specification, illustrate several embodiments of the invention
and, together with the description, serve to explain the principles of the
invention.
FIG. 1 is a block diagram of a computer network shown as a representative
environment for a preferred embodiment of the present invention.
FIG. 2 is a block diagram of a router as used by a preferred embodiment of
the present invention.
FIG. 3 is a block diagram of a DHCP server used by a preferred embodiment
of the present invention.
FIG. 4 is a block diagram of the DHCP message format used by a preferred
embodiment of the present invention.
FIG. 5 is a block diagram of a lease database used in a preferred
embodiment of the present invention.
FIG. 6 is a block diagram of a trusted identifier database as used in a
preferred embodiment of the present invention.
FIG. 7 is a flowchart showing the steps associated with a preferred
embodiment of the IP address lease renewal method of the present
invention.
FIG. 8 is a flowchart showing the steps associated with a preferred
embodiment of the IP address allocation method of the present invention.
FIG. 9 is a flowchart showing the steps associated with a second preferred
embodiment of the IP address lease renewal method of the present invention
.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Reference will now be made in detail to preferred embodiments of the
invention, examples of which are illustrated in the accompanying drawings.
Wherever possible, the same reference numbers will be used throughout the
drawings to refer to the same or like parts.
FIG. 1 shows a computer network 100 as a representative environment for the
present invention. Structurally, computer network 100 includes a series of
client systems 102, of which client systems 102a through 102f are
representative. Each client system 102 may be selected from a range of
differing devices including, but not limited to, the personal computers
shown in FIG. 1. A cable modem 104 is connected to each client system 102.
Each cable modem 104 is connected, in turn, to a cable router 106. Cable
router 106 is connected to a series of server systems 108, of which server
systems 108a through 108e are representative. The use of cable router 106
and cable modems 104 is also intended to be exemplary, and it should be
appreciated that other networking technologies and topologies are equally
practical. It should also be appreciated that a number of different cable
modems and cable routers are available from various manufactures. In
particular, cable modem 104 can be a cable modem sold by Motorola, Inc.,
under the trademark "CYBERSUFR" and cable router 106 can be a cable router
sold by Motorola, Inc., under the trademark "CABLEMASTR."
Router 106 is shown in more detail in FIG. 2 to include a computer system
202 that, in turn, includes a processor, or processors 204, and a memory
206. An input device 208 and an output device 210 are connected to the
computer system 202 and represent a wide range of varying I/O devices such
as disk drives, keyboards, modems, network adapters, printers and
displays. A disk drive 212, of any suitable disk drive type, is shown
connected to computer system 202. A DHCP relay process 214 is shown to be
resident in memory 206 of computer system 202.
A DHCP server system 110 is also included in computer network 100 and
connected to cable router 106. DHCP server system 110 is a computer or
other system that implements Dynamic Host Configuration Protocol (DHCP)
defined in Internet RFC 1541. DHCP server system 110 is shown in more
detail in FIG. 3 to include a computer system 302 that, in turn, includes
a processor, or processors 304, and a memory 306. An input device 308 and
an output device 310 are connected to the computer system 302 and
represent a wide range of varying I/O devices such as disk drives,
keyboards, modems, network adapters, printers and displays. A disk drive
312, of any suitable disk drive type, is shown connected to computer
system 302. A DHCP server process 314, lease database 316 and trusted
identifier database 318 are shown to be resident in memory 306 of computer
system 302.
Client systems 102 and DHCP server system 110 communicate using DHCP
messages. A preferred format for these message is shown in FIG. 4 and
generally designated 400. Structurally, DCHP message includes an op field
402 and an options field 408 (Examination of FIG. 4 shows that each
message also includes a number of other fields. For the sake of brevity,
these fields will not be discussed with particularity). Functionally, each
DHCP message has a type, such as DHCPDISCOVER, DHCPOFFER, DHCPREQUEST or
DHCPACK. The type of each DHCP message is encoded into the options field
408. The options field is also used for a number of other purposes,
including the encoding of vendor-specific information. Each DHCP message
is marked to indicate whether it is being sent from a client system 102 or
a DHCP server system 110. This marking is performed by setting op 402 to
BOOTREQUEST, or BOOTREPLY, respectively. Within a message, the ciaddr
field 404 includes, for certain types of DHCP messages 400, an identifier
that is being passed between a DHCP server system 110 and a client system
102. The chadddr field 406 is used for the machine address of a client
system 102 (also known as a MAC address).
The combination of cable modems 104 and cable router 106 provides a "secure
IP relay agent." Importantly, the secure IP relay agent ensures the
validity of the source address included in the IP header of IP packets
that originate at the client systems 102. More specifically, the secure IP
relay agent "learns" the IP addresses that are assigned to each client
system 102. When an IP packet is received from a client system 102, the
source address of the IP packet is compared to the IP addresses learned by
the secure IP relay agent. If the source address of the IP packet does not
match the learned IP addresses, the IP packet is discarded. The use of IP
address learning is more specificallydescribed in a copending U.S. patent
application Ser. No. 08/762,709 entitled "Method and Apparatus for
Assignment of IP Addresses," naming Wong et al., as inventors, the
disclosure of which is incorporated herein by reference.
The DHCP relay process 214 included in router 106 provides a secure DHCP
relay agent. The secure DHCP relay agent assures that a trusted identifier
is included in each DHCP broadcast message that originates at any of the
client systems 102. More specifically, a trusted identifier is a data
object that specifically identifies a relay agent that is associated with
a single client system 102. In the case of network 100, the cable modems
104 are relay agents that are specifically associated with single client
systems 102. Preferably, each modem 104 includes a unique modem id. This
modem id is used as the trusted identifier. When other networking
technologies and topologies are used, other values or objects may be more
suitably used as the trusted identifier.
Functionally, the trusted identifier may be used to identify the client
system 102 that is the origin of an IP packet, as well as to specifically
direct an IP packet to a specific client system 102. For a preferred
embodiment of the present invention, the DHCP relay process 214 included
in the router 106 encodes the trusted identifier into the vendor-specific
information included in the options field 408 of each DHCP broadcast
message. Since DHCP broadcast messages are processed by DHCP relay process
214 prior to being forwarded to DHCP server system 110, DHCP server system
110 is assured that each message of this type will include the correct
trusted identifier. The use of trusted identifier encoding is also more
specifically described in copending U.S. patent application Ser. No.
08/762,709 entitled "Method and Apparatus for Assignment of IP Addresses,"
naming Wong et al., as inventors.
Within network 100, DHCP server system 110 dynamically allocates IP
addresses to client system 102. This allocation is performed in accordance
with the DHCP protocol defined in Internet RFC 1541. IP addresses
allocated in this fashion are "leased" by the client systems 102. Client
systems 102 that do not periodically renew their leases are in danger of
losing their allocated IP addresses. Each client system 102 uses a lease
identification cookie to identify its lease to the DHCP server system 110.
The client system 102 may choose the lease identification cookie by
sending the DHCP server system 110 a client identifier. Alternatively, if
the client system does not send a client identifier, the DHCP server
system 110 uses the IEEE-style MAC address of the client system 102 as the
lease identification cookie. The client system 102 renews its lease by
sending a DHCP message to the DHCP server system 110 that includes the
lease identification cookie.
DHCP server system 110 maintains IP address leases in lease database 316.
Lease database 316 is more clearly shown in FIG. 5 to include one or more
records 500, each of which includes an IP address lease. Preferably, lease
database 316 includes one record 500 for each IP address that may be
leased by the DHCP server system 110. Each record 500 is accessible using
an IP address index 502. The entries in IP address index 502 correspond to
IP addresses. Functionally, the IP address index 502 provides an apparatus
that associates IP addresses with IP address leases.
Records 500 in lease database 316 that include IP addresses leases that
are, or have been, allocated to client system 102 are a accessible using
lease identifier index 504. The entries in lease identifier index 504
correspond to lease identifiers that are combinations of trusted
identifiers 506 and lease identification cookies 508. In FIG. 5, the
combination of trusted identifier 506 and lease identification cookie 508
is shown as a concatenation. The use of concatenation is intended to be
exemplary and other methods for combining trusted identifier 506 and lease
identification cookie 508 into lease identifiers are equally practical.
Functionally, the lease identifier index 504 provides an apparatus that
associates lease identifiers with IP address leases. For the described
embodiment, the records 500 that include IP addresses leases that have
never been allocated to a client system 102 are not included in lease
identifier index 504. Alternatively, these records 500 may be assigned to
a special "unassigned" entry included in lease identifier index 504.
DHCP server system 110 also maintains a trusted identifier database 318.
Trusted identifier database 318 includes one or more records 600. Each
record 600 includes one or more leases and is accessible using a trusted
identifier index 602. The entries in trusted identifier index 602
correspond to trusted identifiers. Functionally, trusted identifier index
602 provides an apparatus that allows IP address leases to be associated
with trusted identifiers. Alternately, the trusted identifier database 318
may be eliminated by providing a trusted identifier index for lease
database 316. Each entry in the trusted identifier index of lease database
316 corresponds to a particular trusted identifier and each entry may be
used to retrieve the IP address leases associated with the particular
trusted identifier.
A preferred method for renewal of an IP address lease by DHCP server system
110 is shown in FIG. 7 and generally designated 700. Method 700 begins
with step 702 where DHCP server system 110 receives a broadcast
DHCPREQUEST message from a client system 102. For the purposes of
illustration, it is assumed that the DHCPREQUEST message does not identify
a specific DHCP server 110. Thus, according to the DHCP protocol, the
received message is a request from a client system 102 for renewal of an
existing lease.
In step 704, the DHCP server system 110 extracts the trusted identifier
from the received message. More specifically, and as previously described,
each broadcast DHCP message that reaches the DHCP server system 110
includes a trusted identifier. In step 704, this trusted identifier is
retrieved, by the DHCP server 110, from the vendor-specific information
included in the options field 408 of the received message.
The DHCP protocol allows the client system 102 to include a lease
identification cookie in the ciaddr field 404 of each DHCPREQUEST message
for lease renewal. Alternatively, if a lease identification cookie is not
included the ciaddr field 404, the DHCP protocol requires that the
contents of the chaddr field 406 be used as the lease identification
cookie. In step 706, the DHCP server system 110 extracts the lease
identification cookie from the ciaddr field 404 or the chaddr field 406 of
the received message.
In step 708 the trusted identifier retrieved in step 704 and the lease
identification cookie retrieved in step 706 are combined to create a lease
identifier. Generally, the combining of the trusted identifier and the
lease identification cookie may be performed by a number of techniques
including, but not limited to, concatenation. The particular method for
combination, must, however be compatible with the method used to generate
the entries in the lease identifier index 504 of the lease database 316.
In step 710, the DHCP server system 110 uses the lease identifier generated
in step 708 to retrieve a record 500 from lease database 316. More
specifically, in step 710, the DHCP server system 110 searches lease
identifier index 504 of lease database 316 for an entry that matches the
lease identifier generated in step 708. When a matching entry is found,
the corresponding record 500 in lease database 316 is retrieved.
Alternatively, the search of lease database 316 terminates if no entry in
lease identifier index 504 matches the lease identifier. Importantly, the
search of lease database 316 using the combination of the trusted
identifier and the lease identification cookie ensures that each client
system 102 may only retrieve records 500 that are associated with the
client system 102. Thus, client systems 102 may only access their own
leases, regardless of the lease identification cookie included in the
DHCPREQUEST message received in step 702.
Step 710 is followed by step 712 where the DHCP server system 110 analyzes
the results of the search of lease database 316. If step 712 determines
that the search of lease database 316 terminated without locating a record
500, execution of method 700 continues at step 714. In step 714, a DHCPNAK
message is sent by the DHCP server system 110 to the client system 102
indicating that the DHCP server system 110 was unable to comply with the
request to extend the IP address lease of the client system 102.
Typically, step 714 will be executed when the client system 102 has
attempted to extend a nonexistent or otherwise invalid IP address lease.
If step 712 determines that the search of lease database 316 located a
record 500, execution of method 700 continues at step 716. In step 716,
the DHCP server system 110 compares the lease included in the retrieved
record 500 with the DHCPREQUEST message received in step 702. If the terms
of the lease continuation are not acceptable to the DHCP server system
110, method 700 continues at step 718 where the DHCP server system 110
returns a DHCPNAK message to the client system 102. Typically, step 718
will be executed when the client system 102 has attempted to change the
terms (as part of the DHCPREQUEST message) of the IP address lease.
If the terms of the lease continuation are acceptable to the DHCP server
system 110, method 700 continues at step 720. In step 720, the DHCP server
system 110 determines if the lease included in the retrieved record 500
has expired. If not, method 700 continues at step 722 where the DHCP
server system 110 updates the lease database 316 to indicate that the
lease included in the retrieved record 500 has been renewed by the client
system 102. Step 722 is followed by step 724 where the DHCP server system
110 sends the client system 102 a DHCPACK message. The DHCPACK message
informs the client system 102 that the IP address lease has been renewed.
If the DHCP server 110 determines, in step 720, that the lease included in
the retrieved record 500 has expired, method 700 continues at step 726. In
step 726, the DHCP server system 110 uses the trusted identifier extracted
in step 704 to search the trusted identifier database 318. More
specifically, the DHCP server system 110 uses the retrieved trusted
identifier to search the trusted identifier index 602 of the trusted
identifier database 318. If an entry is found in the trusted identifier
index 602 that matches the retrieved trusted identifier, the DHCP server
system 110 retrieves the corresponding record 600.
In step 728 the DHCP server system 110 generates a count of IP addresses
that are currently leased to the client system 102 associated with the
trusted identifier. This is done by counting each IP address lease
included in the record 600 retrieved in step 726. If no record was
retrieved in step 726, the count is set to zero. The count generated in
step 728 is compared, in step 730, to a preset limit. If the count exceeds
the preset limit, execution continues at step 732 where a DHCPNAK message
is sent by the DHCP server system 110 to the client 102. Execution of step
732 occurs when the DHCP server system 110 determines that the client
system 102 has already leased the maximum number of IP address leases that
are available to a single client system 102. In this way, client systems
102 are prevented from "hogging" IP address leases.
If step 730 determines that the client system 102 has not exceeded the
maximum number of allowed IP address leases, execution of method 700
continues at step 734. In step 734, the DHCP server system 110 updates the
lease database 316 to indicate that a new IP address lease has been
granted to the client system 102. The lease database 316 is updated by
modifying the record retrieved in step 710 to include the terms of the IP
address lease granted to the client system. The trusted identifier
database 318 is also updated. More specifically, if the trusted identifier
database 318 includes a record 600 corresponding to the trusted identifier
then the new IP address lease is added to this record 600. In the
alternative, the DHCP server system 110 creates a new record 600 and
includes the new IP address lease in the new record 600. Step 734 is
followed by step 736 where the DHCP server system 110 sends the client
system 102 a DHCPACK message. The DHCPACK message informs the client
system 102 that the client system 102 has been granted an IP address
lease.
A preferred method for allocation of an IP address by DHCP server system
110 is shown in FIG. 8 and generally designated 800. Method 800 begins
with step 802 where DHCP server system 110 receives a broadcast
DHCPDISCOVER message from a client system 102. In step 804, the DHCP
server system 110 extracts the trusted identifier from the received
message. More specifically, and as previously described, each broadcast
DHCP message that reaches the DHCP server system 110 includes a trusted
identifier. In step 804, this trusted identifier is retrieved, by the DHCP
server 110, from the vendor-specific information included in the options
field 408 of the received message.
The DHCP protocol allows the client system 102 to include a lease
identification cookie in the ciaddr field 404 of each DHCPDISCOVER message
for lease renewal. Alternatively, if a lease identification cookie is not
included the ciaddr field 404, the DHCP protocol requires that the
contents of the chaddr field 406 be used as the lease identification
cookie. In step 806, the DHCP server system 110 extracts the lease
identification cookie from the ciaddr field 404 or the chaddr field 406 of
the received message.
In step 808 the trusted identifier retrieved in step 804 and the lease
identification cookie retrieved in step 806 are combined to create a lease
identifier. Generally, the combining of the trusted identifier and the
lease identification cookie may be performed by a number of techniques
including, but not limited to, concatenation. The particular method for
combination, must, however be compatible with the method used to generate
the entries in the lease identifier index 504 of the lease database 316.
In step 810, the DHCP server system 110 uses the lease identifier generated
in step 808 to retrieve a record 500 from lease database 316. More
specifically, in step 810, the DHCP server system 110 searches lease
identifier index 504 of lease database 316 for an entry that matches the
lease identifier generated in step 808. When a matching entry is found,
the corresponding record 500 in lease database 316 is retrieved.
Alternatively, the search of lease database 316 terminates if no entry in
lease identifier index 504 matches the lease identifier. Importantly, the
search of lease database 316 using the combination of the trusted
identifier and the lease identification cookie ensures that each client
system 102 may only retrieve records 500 that are associated with the
client system 102. Thus, client systems 102 may only access their own
leases, regardless of the lease identification cookie included in the
DHCPDISCOVER message received in step 802.
Step 810 is followed by step 812 where the DHCP server system 110 analyzes
the results of the search of lease database 316. If step 812 determines
that the search of lease database 316 located a record 500, execution of
method 800 continues at step 814. In step 814, the DHCP server system 110
determines if the lease included in the retrieved record 500 has expired.
If not, method 800 continues at step 816 where the DHCP server system 110
updates the lease database 316 to indicate that the lease included in the
retrieved record 500 has been allocated to the client system 102.
Preferably, the retrieved record 500 is updated by the DHCP server 110 to
limit the IP address lease allocated to the client system 102 to a
relatively short d | | |
