EP1900179A2

EP1900179A2 - Method for obtaining configuration data for a terminal by using the dhcp protocol

Info

Publication number: EP1900179A2
Application number: EP06778966A
Authority: EP
Inventors: Stéphane TUFFIN; François BOURDAIS
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2005-06-28
Filing date: 2006-06-22
Publication date: 2008-03-19
Also published as: FR2887723A1; US20080279116A1; WO2007000552A3; WO2007000552A2

Abstract

The method comprises a step consisting of inserting, into a predefined option field, a DHCP query emitted by a DHCP client module for obtaining configuration data, optional data containing an identifier, directly or indirectly, to a single user of said terminal with the aim of obtaining configuration data personalized for said user.

Description

Method for obtaining configuration data for a terminal using DHCP

The invention relates to a method for obtaining configuration data for a terminal by using the DHCP protocol. More specifically, the subject of the invention is a method for obtaining configuration data of a terminal as well as a method for processing by a server one or more DHCP requests issued by a DHCP client module of a terminal for obtaining configuration data from said terminal. Dynamic Host Configuration Protocol (DHCP) enables a network-connected terminal to obtain configuration data, including an Internet Protocol (IP) address, from a processing server connected to that same network. This protocol defines a set of requests for establishing a dialogue between, on the one hand, a client module implemented in the terminal and, on the other hand, a server module implemented in the server. These requests are sent either directly from the client module to the server module and vice versa, or through a DHCP relay.

The DHCP protocol can be used for different types of terminals: PC, router, IP phones, SetTopBox, videophones, video camera, etc., as such a terminal includes a DHCP client module able to communicate with a DHCP server module. Such terminals are hereinafter referred to simply as IP terminals.

To account for this wide variety of IP endpoints when processing DHCP requests, DHCP specifies that DHCP requests issued from a given terminal must contain the MAC address of the terminal. This MAC address uniquely identifies the network interface of the terminal, but it is insufficient to determine the nature of the terminal.

The DHCP protocol furthermore provides that the DHCP requests may contain optional data making it possible to manage the diversity of the terminals or the diversity of the needs of the users of these terminals. These optional data are inserted into an option field of the query and include for example:

data that identifies the type of terminal, this data being sent using DHCP option 60 ("Vendor Class Identifier");

data that identifies a group of users or a set of applications associated with that user group, this data being sent using option 77 of the DHCP protocol ("User Class"); data that identifies the incoming network line of the request, when the requests are intercepted by a DHC relay interconnecting at least two networks, this data being sent using the option 82 of the DHCP protocol.

These different data make it possible to appropriately handle the DHCP request that contains them. Indeed, it is possible in particular to generate a response that is a function of either the type of transmitting terminal, the user group or the arrival network of the request. In particular, the generated IP address may be a function of this data. The dynamic assignment of IP address to the terminals of a network can thus be executed automatically, from such data.

However, there are special cases in which some users, belonging to a given user group, may have specific needs in terms of network configuration. Some users may therefore need a static IP address - not a dynamic IP address - that allows them to access a particular service, for example a database that performs user identification. from its IP address and determines the access rights to the database data accordingly.

A known solution to this type of problem is to manually assign a static IP address to the terminal. The disadvantage is that this solution involves the intervention of computer maintenance personnel for each case. In addition, it only works if the need is for a static IP address.

One of the aims of the invention is to provide a method for obtaining configuration data of a terminal by means of DHCP requests as well as a method for processing such requests, which do not have the drawbacks mentioned above for the previous solutions, which are compatible with the DHCP protocol and allow in particular a configuration data management of different terminals of a network that is fully automated and adaptable to the specific needs of certain users. For this purpose, the subject of the invention is a method for obtaining configuration data of a terminal, the terminal comprising a DHCP client module able to communicate via a network with at least one DHCP server module according to the DHCP protocol, the method comprising the following steps:

generating by said DHCP client module one or more DHCP requests for obtaining configuration data from said terminal, transmission of said one or more DHCP requests via said network by said DHCP client module to said at least one DHCP server module,

receiving configuration data received by said DHCP client module in response to at least one of said one or more DHCP requests, the method further comprising a step of inserting into a predefined option field at least one of the requests DHCP, optional data comprising an associated identifier, directly or indirectly, to a single user of said terminal, the received configuration data being customized for said user. The insertion in one of the requests of an identifier, associated with one and only one user of the terminal, allows the generation of a response to this request which is personalized for a given user, identified, indirectly or indirectly by the identifier inserted. . In this way, the configuration data can be generated to meet the specific needs of a given user. In addition, the method makes it possible to envisage a control over the generation of configuration data, and in particular to carry out an identification of the user as soon as he is connected to the network, or even to refuse the assignment of configuration data so as to prevent a user from accessing the network. Securing access to the network therefore occurs at the request of configuration, and is thus reinforced.

The method additionally provides a practical answer to situations of nomadism in which the same user can connect to a network using each time a different terminal, for example by using a terminal among a plurality of terminals accessible self-service. Finally, the method is further compatible with DHCP and does not require modification of the basic principles of this protocol.

According to an advantageous embodiment, the method comprises a step of reading all or part of the optional data in a personal recording medium accessible from the terminal. Such a recording medium is typically a smart card. This embodiment makes it possible to facilitate the step of inserting the identifier in the DHCP request, a simple smart card reader device being necessary.

According to a variant of this embodiment, the personal recording medium is a medium whose access is secured by an identification code. This makes it possible to secure access to this identifier and its introduction in the request and reduces the chances of successful fraudulent use of personal recording media.

According to another variant of this embodiment, the personal recording medium is of the removable media type. A user in a situation of mobility can thus bring his removable support to find a suitable and personalized configuration whatever the terminal he uses.

According to another variant of this embodiment, the personal recording medium is integrated in a mobile terminal and is accessible from said terminal by a local communication link established between said terminal and said mobile terminal. This variant avoids the user of a mobile terminal, for example a mobile phone, to provide additional support for the storage of the identifier.

The identifier can be for example:

an identifier of said user, a registration identifier of a personal recording medium associated with said user,

an identifier of an object associated with said user,

an identifier of a service associated with said user,

a user profile identifier associated with said user. Any type of identifier can thus be used to implement the method according to the invention, it is not necessary to have an identifier of the user himself. For example, the use of a registration identifier of a personal recording medium as identifier facilitates the implementation of the method, since such an identifier is pre-existing and databases are available. known mechanisms for processing such identifiers, and if necessary, to determine the identity of the user from such identifiers.

According to an advantageous embodiment, all or part of the optional data are inserted into the request in encrypted form. This increases the confidentiality of exchanges and limits the chances of successful fraudulent login attempts.

The invention also relates to a terminal comprising a DHCP client module, suitable for implementing the method according to the invention and comprising

a module for causing said optional data to be inserted in said predefined option field; a module for causing all or part of said data to be read; optional in a personal recording medium belonging to said user and accessible from the terminal.

In a complementary manner, the subject of the invention is also a method of processing by a server one or more DHCP requests issued by a DHCP client module of a terminal for obtaining configuration data of said terminal, the server comprising a DHCP server module capable of communicating with the DHCP client module via a network according to the DHCP protocol, at least one of said one or more received DHCP requests comprising, in a predefined option field, optional data including an associated identifier, directly or indirectly to a single user of said terminal, the method comprising the steps of

generating the requested configuration data, the configuration data being personalized for said user,

transmitting to the DHCP client module the configuration data in response to at least one of said one or more DHCP requests.

According to an advantageous embodiment, the generated configuration data comprise an IP address whose static or dynamic type is a function of said identifier. The method thus makes it possible to set up an automatic static address management process based on the knowledge of each of the identifiers associated with the users who need a static address.

According to an advantageous embodiment, the method comprises a step of recording for each request comprising said predefined option field tracking data including date and / or time of receipt of said request. In this embodiment, it is possible to follow a given user with the identifier or identifiers associated with it and consider the establishment of billing function or connection tracking.

According to an advantageous embodiment, the method comprises steps of determining the identity of said user from said identifier, generating the requested configuration data according to the identity of said user in case of identification of the user, to refuse the generation of the requested configuration data in the case where said user is not identified. This embodiment makes it possible to reinforce the security of access to the network from the stage of processing configuration requests.

The invention also relates to a server comprising a DHCP server module, suitable for implementing the processing method according to the invention, and comprising a module for generating said requested configuration data according to said identifier.

According to an advantageous embodiment, the server comprises a database comprising a list of identifiers, and for each identifier of the data corresponding to a description of the configuration requirements of the user associated with this identifier.

Other objects, features and advantages of the invention will become apparent from the description which follows, given solely by way of non-limiting example, and with reference to the appended drawings in which - FIG. 1 is a simplified representation of the invention. architecture of a system for implementing the invention,

- Figure 2 schematically illustrates different phases of the method according to the invention as well as data exchanges between the entities concerned by these different phases. The invention is described in the context of its application to a situation in which a customer of a service provider wishes to access services made available through terminals accessing a network. The terminals are, in this example, self-service terminals.

The customer begins by registering with the service provider for certain predefined services. In exchange, the service provider gives him a smart card. This smart card contains information about the customer himself (ID

Y), service type information (the customer has subscribed to the X service, the customer has subscribed to a 12-month subscription) or mixed information (the customer Y has subscribed to the service X for 12 months). The customer buys or obtains from the service provider a terminal to access the subscribed services. This terminal has a standard configuration, which is for example a configuration allowing only local use, without a network connection, of this terminal. To allow access to the services subscribed by a given user, it must be configured appropriately, and in particular have a DHCP address to access the services implemented via the network. Thanks to the invention, this terminal can be configured each time according to the identity of the user who connects to the network via this terminal, and this as soon as the connection to the network of the terminal is restored.

Figure 1 shows in a simplified manner the main elements cooperating in a system of such a terminal. In the system shown, the terminal 100 is in communicating via a communication network 50 with a data processing server 200 accessing a database 300.

In this example, the terminal 100 is a microcomputer. In general, this terminal can be any type of terminal including a DHCP client module allowing access to the network 50.

The terminal 100 comprises a network card 1 15 compatible with the communication network 50. It also includes a 125 smart card reader. As a variant, the smart card reader 125 can be, not integrated in the terminal

100, but connected to this terminal 100 via an external communication port or in communication link with the terminal 100.

The terminal 100 includes various software modules:

a DHCP client module 1, a driver 140 adapted to the smart card reader, a read module 150 accessing via the driver 140 to the data of the smart card, a data insertion module 170 used in combination with the DHCP client module 1 10,

a communication interface 160 of the middleware type enabling communication between the reading module 150 and the insertion module 170. The DHCP client module 1 10 of the terminal is adapted to interface with the data insertion module 170. Either the DHCP client module 1 10 includes a software interface for communicating or interfacing with the insertion module 170, or it fully integrates the data insertion module 170.

The smart card acts as a personal recording medium. Any other form of personal recording medium capable of storing data can also be envisaged: a USB electronic key connected via a USB port, a SIM card of a mobile phone accessible via a Bluetooth link between the terminal and the telephone, etc. The means of access to the recording medium (in the example described, the driver 140) are each adapted to the recording medium used. Preferably the access to the recording medium is secure so as to prevent fraudulent access to the data it contains or identity theft. This access security usually consists in allowing access to the data of the smart card only after provision of a confidential code.

Preferably, the recording medium is a removable chip card type medium so that a given user can easily, even when is in frequent motion, connect from any terminal while finding a configuration appropriate to its needs.

Returning to FIG. 1, the data processing server 200 comprises a network interface card 215 compatible with the communication network 50. It also includes a software module called DHCP 210 server module.

The DHCP client module and the DHCP server module are designed to interact with each other according to the DHCP protocol as defined by the IETF ("Internet Engineering Task Force") in the RFC 2131 standard. This protocol defines in particular how a client terminal comprising a DHCP client module obtains its network configuration (its IP address, in general) from a DHCP server including a DHCP server module.

The requests sent by the client module to the server module are for example:

a "DHCP DISCOVER" request by which the client module tests the presence of one or more DHCP servers on the network and requests the establishment of a dialogue with one of these servers;

a "DHCP REQUEST" request by which the client module requests configuration data from the server that has responded to its previous "DHCP DISCOVER" request; a "DHCP REQUEST RENEWAL" request by which the client module renews its previous "DHCP REQUEST" request.

DHCP requests issued by a DHCP client module may contain optional data. This data is identified in a DHCP request by an option code. For example, an option code 60 indicates the presence of data identifying the type of terminal.

According to the invention, an option field provided in the DHCP protocol is used to insert, in the DHCP request sent by the DHCP client module, an option code and data associated with this option code.

The inserted DHCP option complies with RFC 2489 standard. It is defined by: - an option code, for example code 180,

a parameter indicating the format of the data associated with the option, for example "string",

a parameter indicating the quantity of data associated with the option, for example in the form of a number of characters. In the rest of the description, such an option will be named "option 180" or "user option". This predefined option code identifies the option field in which the identifier is inserted and is indicative that the configuration data requested by the client module is to be generated according to said identifier, and more specifically, that they are to be personalized. for the user associated with this identifier. According to the invention, the data associated with the option code 180 includes an identifier associated, directly or indirectly, with one and only one user of the terminal 1, 10. Such an identifier makes it possible to determine without ambiguity the identity of the associated user. to this identifier.

Such an identifier can be, at choice: - an identifier of the user himself, for example his surname, first name;

an identifier of the user himself in coded form, which is attributed to this user and makes it possible to identify him among other users within a given organization; it may be for example an employee identifier assigned to the user in the company for which he works or a customer identifier assigned to the user by a service provider organization of which this user is a customer;

- A smart card registration identifier, from which the identity of the user can be determined, the user associated with this identifier being in this case the owner of the smart card; an identifier of the type of telephone number from which the identity of the user can be determined, the user associated with this identifier being in this case the subscriber to the telephone line identified by this number,

an identifier of an object or service associated with a single user,

an identifier of an abstract entity associated with a single user, for example a user profile identifier associated with this user, etc.

A predefined option code identifying said option field is preferably used to indicate the presence of such an identifier and to indicate to the request processing module that the requested configuration data are to be customized for the user associated with the request. this identifier. Other data can also be inserted into the query. These may or may not be extracted from the smart card. In particular, it may be useful to insert data identifying or describing a user profile. It can indeed be envisaged that a user needs to connect with different types of profiles to the terminal. For example, a user profile includes identification information of the services accessible from the terminal to which this user has subscribed. A User profile can also include information on the conditions of access to these services: time slot, number of access, etc.

As a variant, only a profile identifier is inserted in the request, the server

200 being in this case able to return the information related to the services associated with this profile from the database 300.

In addition, as indicated above, the profile identifier may be the only data item integrated into the option field 180 because it can be used to identify the terminal user if this profile identifier is associated with a user. and only one. For this purpose, the database preferably comprises a list of identifiers, and for each identifier of the corresponding data, either information relating to the services subscribed by the user associated with this identifier, or to a description of the configuration requirements of the the user associated with this identifier (type of address, access rights, etc.), or the configuration data themselves (in the case of a static address, it is necessary to memorize it). In this way, the server is thus able, without even knowing the identity of the user, to generate custom configuration data. The data inserted in the request and associated with the option code 180 are preferably extracted from the smart card. In addition, data from different sources, for example non-confidential data, can also be inserted into the request.

Some or all of the data associated with option 180 may be encrypted. The encryption of these data can be done, either before insertion of the data in the request, or before recording of the data on the smart card. In this second variant, the risks of identity theft are very low, especially if access to the information medium is moreover secure.

FIG. 2 illustrates the different phases of the method according to the invention as well as the data exchanges carried out during these different phases between the terminal

100, the server 200, the reader 120 and the database 300. After startup of the terminal 100 and insertion of the smart card 130 in the reader 120, the steps S10 to S160 proceed as follows:

S10: the terminal 100 generates a request "DHCP DISCOVER" and requests the insertion of an option 180 including data present in the smart card

130; this data notably comprises an identifier associated with a user of the terminal 100; S20: the reader 120 receives a data reading instruction;

S30: the reader 120 reads the data requested in the smart card 130 and sends them back to the terminal;

S40: the terminal 100 receives the data read in the smart card 130; - S50: the terminal 100 inserts the received data in the request "DHCP

DISCOVER ", then sends this request to the server 200;

S60: the server 200 receives the request "DHCP DISCOVER";

S70: the server 200 processes the request "DHCP DISCOVER" by accessing S75 if necessary to the database 300; this processing is carried out taking into account all or part of the data read in the card and inserted in the request; the server 200 generates a response that preferably depends on the identifier inserted in the request;

S80: the server 200 sends a response to the request "DHCP DISCOVER" in the form of a request "DHCP OFFER"; - S90: the terminal 100 receives the response "DHCP OFFER";

- S100: the terminal 100 generates a request "DHCP REQUEST" and insert all or part of the previously read data in the card;

- S1 10: the terminal 100 sends this request "DHCP REQUEST" to the server 200; S120: the server 200 receives the request "DHCP REQUEST";

S130: the server 200 processes the request "DHCP REQUEST" by accessing S135 if necessary to the database 300;

S140: the server 200 sends a response to the request "DHCP REQUEST" in the form of a "DHCP ACK" request including an IP address intended for the configuration of the terminal 100;

- S150: the terminal 100 receives the response "DHCP ACK";

- S160: the terminal 100 proceeds to its IP configuration from the IP address returned by the server 200.

The constitution of a DHCP request by the terminal 100 itself comprises the following steps:

the DHCP client module 1 10 creates a DHCP request; the DHCP client module 1 10 transfers this request to the insertion module 170;

the insertion module 170 sends a request to the reading module 150 via the middleware 160 for the extraction of the data from the smart card; the reading module 150 obtains the requested data from the driver 140 of the card reader 120; the reading module 150 sends the requested data to the insertion module 170 via the middleware 160; the insertion module 170 inserts the data in the created DHCP request and the transfer to the DHCP client module 1; the DHCP client module sends the DHCP request to the DHCP server module 210 and waits for its response.

In each generated DHCP request may include an option 180 and associated data. In the example described, the "DHCP DISCOVER" and "DHCP REQUEST" requests contain information on the identity of the user of the terminal. All requests issued by the DHCP client module ("DHCP REQUEST RENEWAL", "DHCP INFORM" and "DHCP RELEASE") may contain this information as needed. According to the embodiments, there will or will not be access to the smart card at each generation of client DHCP request to read the data to be inserted. Thus, step S100 of generating a "DHCP REQUEST" request may require substeps S102 and S103 for access to the smart card and for reading data in the smart card. The DHCP server is configured to use the information set in the chosen DHCP option in different ways:

- To perform access control type operations based on the identity of the user and respond only to terminals sending information associated with a known user; in this case, the security of the DHCP service is improved since only the authorized terminals are configured; in this situation, authentication data (password, certificate, etc.) can be inserted in the DHCP request with the data enabling the user to be identified and allow the server to authenticate the current user of the transmitting terminal of the user. request;

to record tracking data (in particular the date and / or time of receipt of the request) relating to the connections requested by a given user, that is to say for the requests comprising the option field 180; in this case, the service provider can implement billing by user, for example depending on the number of connections or the duration of each connection, the tracking data being crossed with the information linking a customer to a smart card ; - to emit a response that is personalized according to the identity of the user or according to the services this user has subscribed to; for example by generating configuration data according to the identifier and / or the identity of the user. These various operations are preferably performed during the processing of the client DHCP request and before the elaboration of the response to this request. When the operation considered is a simple record of tracking data, it can optionally be executed after sending the response to the client request. By generalizing, the processing by the server 200 of the DHCP request sent by the terminal 100 is performed according to the data of the optional data field. These data comprise an identifier, uniquely associated with the user of the terminal 100. This is in particular an identifier for a unique identification of the user of the terminal 100. From the data associated with the option DHCP, the DHCP server determines, prior to the processing of the DHCP request, the identity of the user of the terminal 100 and processes the request according to the identity of the user. Thus operations such as the recording of tracking data, the processing of the data associated with the request, the access control from the data associated with the request or the generation of the response to the request, can be performed according to the identity of the current user of the terminal 100.

As a variant, the step of determining the identity of the user of the terminal can be avoided, if the server is designed to respond to the request solely on the basis of the identifier, especially if the server comprises a database registering the user configuration requirements in association with the identifier.

For example, if the database 300 comprises a table of the services subscribed by the different users, which table is indexed by a user identifier, the DHCP server identifies from the identifier associated with the user the services subscribed by this user and returns a response (configuration data) that is adapted to the services subscribed.

In particular, the DHCP configuration returned by the server in response to a request "DHCP REQUEST" may be a function of the identifier, and therefore of the identity of this user. It is thus possible to ensure that the type, static or dynamic, of the returned address is also a function of the identity of this user. In the case of example where the user needs a static address, the server will always return a predefined static address tailored to that user's needs.

Claims

A method for obtaining configuration data of a terminal (100), the terminal comprising a DHCP client module (1 10) able to communicate via a network (50) with at least one DHCP server module (210) according to DHCP protocol, the method comprising the following steps: generation by said DHCP client module of one or more DHCP requests for obtaining configuration data of said terminal,

transmission of said one or more DHCP requests via said network by said DHCP client module to said at least one DHCP server module,

receiving configuration data received by said DHCP client module in response to at least one of said one or more DHCP requests, the method being characterized by including a step of inserting into a predefined option field of at least one of said one or more DHCP requests, optional data comprising an associated identifier, directly or indirectly, to a single user of said terminal, and in that said received configuration data is personalized for said user.

2. Method according to claim 1, characterized in that the method comprises a step of reading all or part of the optional data in a personal recording medium accessible from the terminal.

3. Method according to claim 2, characterized in that said personal recording medium is a medium whose access is secured by an identification code.

4. Method according to claim 2 or 3, characterized in that said personal recording medium is removable media type.

5. Method according to any one of claims 2 to 4, characterized in that said personal recording medium is integrated in a mobile terminal and is accessible from said terminal by a local communication link established between said terminal and said terminal. mobile.

6. Method according to any one of claims 1 to 5, characterized in that said identifier is part of the group comprising: an identifier of said user,

a registration identifier of a personal recording medium associated with said user,

an identifier of an object associated with said user, an identifier of a service associated with said user,

a user profile identifier associated with said user.

7. Method according to any one of claims 1 to 6, characterized in that said optional data further comprises data comprising an identification of at least one service to which the user has subscribed.

8. Method according to any one of claims 1 to 7, characterized in that all or part of the optional data are inserted into the request in encrypted form.

9. A method of processing by a server (200) one or more DHCP requests issued by a DHCP client module (1 10) of a terminal (100) for obtaining configuration data of said terminal (100), said server comprising a DHCP server module (210) adapted to communicate with said DHCP client module (1 10) via a network (50) in accordance with the DHCP protocol, said method comprising the steps of

- generate the requested configuration data,

transmitting to said DHCP client module the configuration data in response to at least one of said one or more DHCP requests, the method being characterized in that at least one of said one or more received DHCP requests comprises, in a predefined option field , optional data comprising an associated identifier, directly or indirectly, to a single user of said terminal and in that the generated configuration data is customized for said user.

10. The method of claim 9 characterized in that the generated configuration data comprises an IP address whose static or dynamic type is a function of said identifier.

1 1. Process according to claim 9 or 10, characterized in that the process comprises the steps of

to determine the identity of said user from said identifier; to generate the requested configuration data according to the identity of said user in the event of identification of the user,

- To refuse the generation of the requested configuration data in the case where said user is not identified.

12. Method according to any one of claims 9 to 1 1 characterized in that the method comprises a step of recording for each query comprising said predefined option field of tracking data including date and / or time information of receipt of said request.

Terminal comprising a DHCP client module, suitable for implementing the method according to any one of claims 1 to 8 and comprising

a module for causing the insertion of said optional data in said predefined option field,

a module for causing all or part of said optional data to be read in a personal recording medium associated with said user and accessible from the terminal.

14. A server comprising a DHCP server module, suitable for implementing the method according to any one of claims 9 to 12, and comprising a module for generating said requested configuration data according to said identifier.

15. Server according to claim 14, characterized in that it comprises a database comprising a list of identifiers, and for each identifier of data corresponding to a description of the configuration requirements of the user associated with this identifier.