EP2266286A2 - Procede de commutation d'un terminal mobile d'un premier routeur d'acces vers un deuxieme routeur d'acces - Google Patents

Procede de commutation d'un terminal mobile d'un premier routeur d'acces vers un deuxieme routeur d'acces

Info

Publication number
EP2266286A2
EP2266286A2 EP09730543A EP09730543A EP2266286A2 EP 2266286 A2 EP2266286 A2 EP 2266286A2 EP 09730543 A EP09730543 A EP 09730543A EP 09730543 A EP09730543 A EP 09730543A EP 2266286 A2 EP2266286 A2 EP 2266286A2
Authority
EP
European Patent Office
Prior art keywords
router
terminal
identifier
context
access router
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP09730543A
Other languages
German (de)
English (en)
Inventor
Fabien Allard
Julien Bournelle
Jean-Michel Combes
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP2266286A2 publication Critical patent/EP2266286A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H04W36/0038—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information of security context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices

Definitions

  • the present invention relates to the management of security when switching a mobile terminal of a first access router, to which the terminal is initially connected securely, to a second access router.
  • IPsec IP Security Protocol
  • a phase of establishment of this tunnel includes a negotiation of security parameters necessary for the security of communications, such as for example keys that will be used to encrypt communications between the two entities, cryptographic algorithms, etc.
  • a protocol has been defined to negotiate security settings when using the IPSec protocol. This is the IKE protocol (for "Internet Key Exchange”) in version 2, noted IKEv2.
  • a security association is a data structure that groups together all the parameters associated with a given secure connection between two peers: the security parameters negotiated in IKEv2 exchanges and the source and destination peer IP addresses involved in the connection. communication, such as the terminal and the access router.
  • SA Security Association
  • a database of security associations is used (the term commonly used is the term “Security Association Database”, or "SAD").
  • SAD Security Parameter Index
  • the communication context comprises the IPsec and IKEv2 parameters related to the terminal and the access router: the security associations relating to the communications between the terminal and the access router, their identifiers in the security association base, as well as a security policy that defines what should be applied in terms of security to packets received or transmitted.
  • the context therefore includes all the negotiated security parameters, the IP addresses of the terminal and the access router and the security association identifiers, or SPIs.
  • a first IPsec tunnel is established, and this IPsec tunnel is associated with a communication context comprising at least one security association identified by an index.
  • a second IPSec tunnel When this mobile terminal moves from a first area covered by this first access router to a second area covered by a second access router, a second IPSec tunnel must be established between the mobile terminal and the second router. Establishing this second IPsec tunnel requires restarting IPsec message exchanges from the beginning, including exchanges on the negotiation of security settings. Such an operation is time consuming. In the case of real-time services, such as for example a voice over IP service, or a streaming video streaming service (the term commonly used is the term "streaming video”), it may then be difficult to ensure continuity of service during the mobility of the terminal. To overcome this drawback, it is known to use a context transfer mechanism to transfer the IPSec and IKEv2 context relative to the mobile terminal, from the first router to the second router.
  • a context transfer mechanism to transfer the IPSec and IKEv2 context relative to the mobile terminal, from the first router to the second router.
  • the IPSec and IKEv2 context is then transferred from the first router to the second router during the mobility of the terminal.
  • certain parameters of the received context must be updated by the second router:
  • security association identifiers between the terminal and the access router, if they are already used to identify other active security associations at the second access router.
  • MOBIKE for "IKEv2 mobility and multihoming protocol”
  • IKEv2 mobility and multihoming protocol is adapted to update and modify IP addresses of the access router and the terminal in security associations during a context transfer.
  • security association identifiers it is not possible to update security association identifiers in the case where an identifier transferred in a context during the mobility of a terminal of a first router to a second router is identical to a identifier in use on the second router.
  • the IPSec tunnel can not benefit from context transfer; it must therefore be completely rebuilt, which, in the case of real-time services, does not ensure continuity of service.
  • the invention responds to this need by proposing a method of switching a mobile terminal from a first access router to a second access router, the terminal having previously established a secure connection with the first access router.
  • said context which is associated with a communication context between the terminal and the first router, said context comprising at least one identifier relating to a set of security parameters of the connection, in which method said context is transferred to the second router during the switching of the terminal, characterized in that it comprises, in the case where the at least one identifier in the transferred context is already used by said second router, a step of sending to the terminal by the second router a new identifier for said set security settings.
  • the method according to the invention makes it possible to minimize the time required for the switching of a terminal from an access router to a second access router. Indeed, it allows, during a context transfer and in the event of a collision between at least one context security association identifier transferred with one of the identifiers already used by the second router to manage active security associations, negotiate a new identifier between the terminal and the second router. This negotiation makes it possible to update the security parameters of the context and thus to establish the secure connection from the updated context information. Thus, it is not necessary to renegotiate from the beginning the security settings between the terminal and the second router. It is thus possible to guarantee continuity of service for real-time services running on the mobile terminal.
  • the method comprises, in the case where the new identifier received from the second router is already used by the terminal, a step of sending to the second router of another new identifier for said set of security settings.
  • a terminal that receives a proposal from the second access router of a new identifier is adapted to send to the second router a counterproposal in the case where the new identifier received from the second router collides with an identifier already used by the terminal.
  • the invention also relates to a signal carrying a notification message intended to be transmitted between a terminal and a second router during a switching of said terminal from a first router to said second router, the terminal having previously established a secure connection with the first access router with which is associated a communication context between the terminal and the first router, said context comprising at least one identifier relating to a set of security parameters of the connection, said message comprising:
  • the message is in accordance with the IKEv2 NOTIFY protocol.
  • the notification message used by a router to propose a new identifier to a terminal, or by a terminal to send to a router a counter-proposal containing another new identifier is in accordance with an existing message of a standardized protocol. No new message needs to be defined.
  • the invention also relates to an access router, adapted to manage a switching of a mobile terminal from a first access router to said access router, a secure connection being established between the terminal and the first access router.
  • an access router adapted to manage a switching of a mobile terminal from a first access router to said access router, a secure connection being established between the terminal and the first access router.
  • said context comprising at least one identifier relating to a set of security parameters of the connection
  • said router comprising means for receiving said context during the switching of the terminal, and being characterized in that it further comprises:
  • detection means arranged to detect that the at least one identifier in the transferred context is already used by said access router
  • the means for sending arranged to send to the terminal a new identifier for said set of security parameters in the case where the detection means detect that the at least one identifier in the transferred context is already used by said access router.
  • the invention also relates to a mobile terminal adapted to switch from a first access router to a second access router, said terminal being arranged to establish in advance a secure connection with the first access router, to which is associated a context of communication between the terminal and the first router, said context comprising at least one identifier relating to a set of security parameters of the connection, characterized in that it comprises: means for receiving and processing a new identifier transmitted by the second router, arranged to substitute said new identifier for the identifier relative to the set of security parameters in the communication context when the terminal is switched to the second router.
  • the terminal further comprises:
  • detection means arranged to detect whether the new identifier received from the second router is already used by the terminal, and
  • generating and sending means arranged to generate and send to the second router another new identifier for said set of security parameters, controlled by said detection means.
  • the invention also relates to a computer program for an access router, comprising:
  • code instructions for, in case of transfer to the router of a communication context associated with a secure connection between a terminal and another router and comprising at least one identifier relating to a set of security parameters of the connection, detect if the at least one identifier of the transferred context is already used by said access router, and
  • the invention also relates to a data carrier on which the computer program for an access router according to the invention is stored.
  • the invention also relates to a computer program for a terminal, comprising code instructions for, in case of transfer from a first router to a second router of a communication context associated with a secure connection between the terminal and the terminal.
  • first router the secure connection being associated with a communication context comprising at least one identifier relating to a set of security parameters of the connection, replacing said identifier with a new identifier received from the second router, when the program is executed by a processor.
  • the invention also relates to a data carrier on which the computer program for a terminal according to the invention is stored.
  • FIG. 1 illustrates the principle of the transfer of a communication context that is implemented by the invention
  • FIG. 2 illustrates the message exchanges during a transfer of context from a first router to a second router according to the prior state of the art
  • FIG. 3 shows the steps of the method of the invention according to a particular embodiment
  • FIG. 4a, respectively 4b is a schematic representation of a structure of a notification message according to the prior art, respectively of a notification message according to a particular embodiment of the invention
  • FIG. 5 is a functional block representation of an access router according to one embodiment of the invention
  • FIG. 6 is a functional block representation of a terminal according to one embodiment of the invention.
  • FIG. 1 illustrates a principle implemented by the method of the invention.
  • a mobile terminal T attached to a pRA access router accesses the Internet in a secure manner.
  • the terminal T has established a secure connection with the access router pRA, represented in the figure by a tunnel pT between the terminal T and the access router pRA.
  • the secure connection is established according to the "IPsec" protocol (for "IP security protocol"), for example according to a mode called “tunnel mode”.
  • IPsec for "IP security protocol”
  • the pT tunnel called “IPsec tunnel” makes it possible to secure the communications between the mobile terminal T and the access router pRA.
  • Protocol exchanges are necessary to establish the IPsec tunnel, they include first exchanges to negotiate security parameters that are used to secure the communications between the mobile terminal T and the access router pRA.
  • the first exchanges that make it possible to negotiate the security parameters are compliant, for example with the "IKE" protocol (for "Internet Key Exchange") in version 2, denoted "IKEv2".
  • the parameters negotiated during IKEv2 exchanges are, for example, cryptographic algorithms, encryption keys, a mode, for example tunnel mode, to be used for securing peer-to-peer communications, such as the terminal T and the access router pRA. It is also during the IKEv2 exchanges that data structures called "security associations" (the term commonly used is the term “Security Association”) are defined.
  • a security association is a data structure that groups together all the parameters associated with a given secure connection between two peers: the security parameters negotiated in IKEv2 exchanges, and the source and destination peer IP addresses respectively.
  • IKEv2 exchanges two types of security association are created: - security associations used by the IPsec protocol, once the secure tunnel has been established, to secure peer-to-peer communications; these security associations are later noted as “IPsec security associations”, - security associations used by the IKEv2 protocol to protect the negotiation of IPsec security associations; these security associations are later referred to as "IKE security associations”.
  • the security associations are stored in unrepresented databases, at the terminal T and the access router pRA.
  • the databases are called security association databases (the term commonly used is the term “Security Association Database”, also referred to as “SAD”).
  • SAD Secure Association Database
  • each security association is uniquely identified by an identifier called security parameter index (the term commonly used is the term “Security Parameter Index”, or "SPI”).
  • SPI Security Parameter Index
  • a security association is directional: for a given peer, a security association is applied to a packet reception by that peer, and another security association is applied to a packet transmission by that peer.
  • a communication context associated with the secure tunnel pT.
  • the communication context includes IPsec and IKEv2 parameters related to the terminal T and the access router pRA, and more specifically: the security associations relating to the communications between the terminal and the access router,
  • a security policy that defines what should be applied in terms of security to packets received or transmitted.
  • the mobile terminal T which, during a movement, detects a second access router nRA.
  • the mobile terminal T decides, according to its own criteria to access the network via the second access router nRA.
  • the terminal T must firstly detach from the router pRA through which he accessed the network so far, and secondly attach to the second router nRA. It is said that the terminal T switches the pRA router to the second router nRA.
  • the terminal T To access the network via the second nRA router in a secure manner, the terminal T must establish a secure connection with the second nRA access router. This connection is represented by a tunnel nT.
  • a context is transferred including parameters IKEv2 and IPSec linked to the terminal T and to the first pRA access router.
  • the transferred context includes the security associations relating to the communications between the terminal T and the first pRA access router, the identifiers of these security associations, as well as a security policy that defines what must be applied in terms of security. to packets received or transmitted.
  • the context transfer from the first router pRA to the second router nRA is shown schematically by a dotted arrow from the router pRA to the second router nRA.
  • This context transfer between access routers makes it possible to establish a secure connection between the terminal T and the second router nRA while avoiding a complete negotiation between the terminal T and the second router nRA, in particular the negotiation of the parameters. security using the IKEv2 protocol.
  • the context that is transferred from the router pRA to the second router nRA is then activated on the second router nRA. This activation corresponds to the setting up of the context on the second router nRA.
  • the second nRA router then processes the context. In particular, the context is updated by the second router nRA:
  • a new IP address of the terminal T is specified, insofar as the latter, while moving, has acquired a new IP address
  • an IP address of the access router to which the terminal T is attached is updated with the address of the second access router nRA,
  • security association identifiers used to uniquely identify security associations between the terminal and the access router, if these identifiers are already used to identify other active security associations at the second nRA router.
  • the method for updating the security association identifiers is described in connection with FIG.
  • An existing protocol, "MOBIKE"("IKEv2 mobility and multihoming protocol") is used to update the IP addresses of the router and the terminal.
  • the context transfer makes it possible to transfer from the router pRA to the second router nRA relevant information that is immediately reusable by the second router nRA. As a result of the context transfer, time is saved during switching from the terminal T of the router pRA to the second router nRA.
  • the mobile terminal T attaches to the access router pRA, it negotiates security parameters between the terminal T and the router pRA to establish a secure connection with the access router pRA .
  • the negotiation takes place by means of message exchanges, not detailed, in accordance with the IKEv2 protocol.
  • a communication context is available at the mobile terminal T and the first access router pRA.
  • the context includes the IPsec and IKEv2 security associations associated with the secure connections between the T terminal and the pRA router, the security association identifiers, and a security policy that defines how to handle, in terms of security, packets received or issue.
  • the communication context between the terminal T and the access router pRA comprises the security parameters necessary for securing communications between the terminal T and the access router pRA, the IP addresses of the terminal T and the access router pRA, and the identifiers, or SPI, of the security associations in the base of the security associations SAD.
  • the secure connection is established between the terminal T and the router pRA by means of an IPsec tunnel t20.
  • a context transfer step 21 during which the mobile terminal T moves to the second access router nRA, the communication context established in step 20 is transferred from the access router pRA to second nRA access router.
  • the transfer is carried out by means of message exchanges, not detailed, in accordance with the "CXTP" protocol (of the English "Context Transfer Protocol") between the router pRA, the second router nRA and the terminal T.
  • the messages exchanged to transfer the communication context of the router pRA to the router nRA being known to those skilled in the art and not part of the invention, they will not be further described in the present description.
  • the security associations are updated in the T terminal security association databases and the second nRA access router.
  • the terminal T attaches to the second access router nRA. It is assumed here that the second access router nRA detects a collision between at least one of the security association identifiers received in the context and one of the security association identifiers that it already uses itself.
  • a step 22 of attachment of the terminal T to the second access router nRA comparable to the initial step 20, security parameters are renegotiated between the terminal T and the second access router nRA.
  • a secure connection is established between the terminal T and the second access router nRA. It is represented by a new tunnel t22. It will be noted that, in the prior art, the establishment of the new tunnel t22 necessitates restarting the IKEv2 protocol exchanges from the beginning.
  • the second access router nRA activates the context received and processes it.
  • the second nRA router updates the communication context associated with the communication between the terminal T and the router nRA. For this purpose, messages conforming to the MOBIKE protocol are exchanged between the second router nRA and the terminal T in order to update the IP addresses of the terminal T and the second router nRA in the security associations. The secure connection between the terminal T and the second router nRA is then established.
  • step initial 30 comparable to step 20 of Figure 2, the mobile terminal T attaches to the access router pRA.
  • security parameters negotiation of security parameters to establish the secure connection between the terminal T and the access router pRA.
  • the communication context associated with the secure connection between the two peers is defined at the mobile terminal T and the access router pRA.
  • the secure connection is established between the terminal T and the router pRA by means of an IPsec tunnel t30.
  • the terminal T attaches to the second access router nRA.
  • the second access router nRA detects a collision between at least one of the security association identifiers received in the communication context, and one of the security association identifiers that it already uses. The collision may concern one or more identifiers.
  • the identifiers that he already uses correspond, for example, to secure connections he has established with other unrepresented terminals.
  • the second nRA router activates the received context and begins processing it.
  • the old IPsec tunnel t30 which secured the communications between the terminal T and the access router pRA has been transferred between the terminal T and the second access router nRA.
  • This tunnel is represented by an old tunnel transferred 131.
  • the context associated with the old tunnel transferred t31 has not yet been updated.
  • the second access router nRA updates the communication context associated with the secure connection between the terminal T and the second access router nRA. For this purpose, messages conforming to the MOBIKE protocol are exchanged between the second router nRA and the terminal T in order to update the IP addresses of the terminal T and the second access router nRA in the security associations associated with the secure connection. and, according to the invention, to negotiate new security association identifiers between the terminal and the access router nRA, replacing the identifier or identifiers for which a collision has been detected.
  • the purpose of negotiating new identifiers is to find security association identifiers for the secure communication between the terminal and the access router nRA which are not already used by the second access router nRA and, if appropriate by means of the terminal T.
  • an "INFORMATIONAL" message m32-1 carrying at least one notification datum is sent.
  • the message m32-1 carries an update notification of peer IP addresses, denoted "N (UPDATE_SA_ADDRESSES)" and as many notifications according to the invention, denoted "N (UPDATE_SPI)" and each comprising a new security association identifier, than identifiers detected as already used during the attachment sub-step 310.
  • N UPDATE_SA_ADDRESSES
  • N UPDATE_SPI
  • the terminal T which receives a proposal for at least one security association identifier in the message m32-1, detects a collision between the identifier received. the second access router nRA and a security association identifier that it already uses to manage a secure connection with another peer not shown. The terminal then sends in a message m32-2 according to the invention a proposal for another new identifier.
  • the proposal relates to one or more identifiers depending on whether there is a collision with one or more identifiers managed by the terminal T.
  • the latter sends a proposal for at least one security association identifier in an m32-3 message.
  • a message according to the invention used to propose new identifiers of security associations in the event of a collision detected by the second router nRA during a transfer of context from the access router pRA will now be described in connection with Figures 4a and 4b.
  • Figure 4a is a representation of a protocol-compliant message
  • IKEv2 of INFORMATIONAL type containing NOTIFY type data Such a message is usually used during MOBIKE-compliant exchanges to convey a message about an error or notification. It can for example be transmitted such a message to notify a recipient peer a new IP address of the sending peer. In the latter case, the transmitted notification uses a type "UPDATE_SA_ADDRESSES".
  • the "Protocol ID" field specifies the type of the security association: IKE or IPsec.
  • the "SPI size" field specifies the length of the SPI identifier or zero.
  • the "Notify Message Type” field specifies the type of the notification message. For example, "UPDATE_SA_ADDRESSES”.
  • the "Security Parameter Index" field contains the SPI identifier.
  • the "Notification Data” field specifies the informational data, or the error transmitted in addition to the "Notify Message Type”.
  • a new type of notification adapted to enable a peer to propose a new security association identifier when this peer detects a collision between an identifier is defined. that he is already using and a security association identifier he receives.
  • the detection of a collision between identifiers can take place during a transfer of context from an access router to a second access router. In another case, the detection can take place after receiving a message containing a proposal for a new identifier according to the invention.
  • the message according to the invention is comparable to a notification message as described in relation with FIG. 4a.
  • a new type "UPDATE_SPI” makes it possible to characterize the type of the notification.
  • a message of type "UPDATE_SPI” is adapted to propose a new security association identifier instead of an identifier already used.
  • the "Security Parameter Index” field includes the SPI identifier to be replaced.
  • the "New Security Parameter Index” field includes the new identifier, generated to avoid collision with the identifier of the "Security Parameter Index” field.
  • a "D” direction flag makes it possible to specify whether the identifier to be modified is on the terminal side, or on the access router side.
  • the flag is coded on one bit and is "O” if it is on the terminal side, and "1" if it is on the access router side.
  • the IKEv2 message includes several "UPDATE_SPI" type notifications.
  • An access router 50 provides a basic function of a router: the routing of packets.
  • it allows a terminal to access one or more networks.
  • it is adapted to establish a secure connection with the terminal that attaches to him to access the network.
  • secure connections are established using the IPsec protocol.
  • the router 50 according to the invention is adapted to receive and transmit to other routers communication contexts, associated with secure connections established with peers such as terminals. It is also adapted to negotiate with these peers new security association identifiers associated with secure connections when it detects collisions between at least one identifier present in a context that it receives, and one of the identifiers that it uses.
  • the access router 50 comprises several modules: network interfaces 51, a memory 52, a reception and context transfer module 53, a detection module 54, a sending and receiving module 55 a proposal for at least one new security association identifier, a generation module 56 and databases 57.
  • the modules 51, 52, 53, 54, 55, 56 and 57 are connected to a microprocessor 58 :
  • the network interfaces 51 allow on one hand a terminal or another access router to communicate with the access router 50 according to different technologies, for example according to a WiFi mode, WiMax, and they also allow the access router 50 to access one or more networks, for example the Internet and thus provide network access to the terminal or router that has attached to it; databases 57 are dynamically created when establishing secure connections between the router and peers.
  • These bases include the SAD database of security associations and a security policy database (the term commonly used is the term "Security Poiicy Database", or "SPD”) which defines what should be applied, in terms of security, to packets received or transmitted.
  • the memory 52 makes it possible to perform calculations, to manage the databases 57, to load software instructions corresponding to the steps of the switching management method described above, and to execute them by the microprocessor 58; the microprocessor 58, or "CPU" (of the English "Central Processing
  • Unit is a processing unit
  • a receiving and context transfer module 53 arranged to receive from another access router a context associated with a secure communication previously established between the other access router and the terminal, and to transfer an associated context secure communication to another router;
  • a detection module 54 arranged to detect collisions between at least one of the security association identifiers received during the transfer of a context associated with a terminal from another router, and one of the security association identifiers that it already uses, for example in the context of secure communications already established with another terminal; a module 55 for sending and receiving at least one proposal for a new identifier;
  • a generation module 56 arranged to generate at least one new identifier in the case where the detection module detects a collision between at least one identifier that it receives in a context that is transferred to it by another router or enters least an identifier that it receives from a terminal in an identifier proposal, and at least one identifier that it already uses. It is also arranged to generate a proposal relating to this at least one new identifier.
  • the sending and receiving modules 55 and the generating module 56 cooperate to send a new security association identifier when a collision has been detected by the detection module 54.
  • the modules 53, 54, 55 and 56 are arranged to implement those of the steps of the switching method described above which are implemented by the access router. These are preferably software modules comprising software instructions for executing the steps of the switching method described above, implemented by a processor of an access router.
  • the invention therefore also relates to: a computer program comprising instructions for implementing the switching method as described above when this program is executed by a processor;
  • the software modules can be stored in, or transmitted by, a data carrier.
  • a data carrier This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a transmission medium such as a signal or a telecommunications network.
  • a mobile terminal 60 according to the invention has conventional functions of access to a network, for example the Internet, by attachment to an access router.
  • the mobile terminal 60 is arranged to establish a secure connection with an access router to which it attaches.
  • the mobile terminal 60 comprises several modules: network interfaces 61, a memory 62, a module 63 for receiving and processing a new security association identifier, a module 64 for generating and sending a new identifier. security association, a detection module 65 and databases 66.
  • the modules 61, 62, 63, 64, 65 and 66 are connected to a microprocessor 67:
  • the network interfaces 61 are adapted to access a network by attachment to access routers and to detect the presence of access routers in a geographical area.
  • the attachment to an access router can be done according to different technologies, for example according to a WiFi mode;
  • the databases 66 are dynamically created during the establishment of secure connections between the terminal and routers. These bases include the SAD base of security associations and a security policy SPD which defines what must be applied in terms of security to packets received or transmitted.
  • the memory 62 makes it possible to perform calculations, to manage the databases 66, to load software instructions corresponding to the steps of the method of processing a new identifier by the mobile terminal described above, and to have them executed by the microprocessor 67;
  • the microprocessor 67 or "CPU” is a processing unit;
  • the module 63 for receiving and processing a new identifier is arranged for, when switching the terminal of a first router to a second router and in the case where a collision between identifiers of security associations relating to a set of security parameters is detected, receive a new identifier transmitted by the second router and substitute it for an identifier used by the terminal for a security association in the security association database;
  • the module 64 for generating and sending new identifier is arranged to generate and send, if necessary, a new identifier to the access router in the case where the identifier received from the access router is already used by the terminal to identify an active security association.
  • the detection module 65 is arranged to detect, upon receipt of a security association identifier sent by an access router, the identifier is already used by the terminal to identify an active security association;
  • the modules 63, 64 and 65 are arranged to implement those of the previously described steps of the switching method that are implemented by the mobile terminal. These are preferably software modules comprising software instructions for executing the steps of the switching method of a mobile terminal by the terminal.
  • the invention therefore also relates to: a computer program comprising instructions for implementing the method of switching a terminal as described above when this program is executed by a processor;
  • the software modules can be stored in or transmitted by a data carrier.
  • This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a transmission medium such as a signal, or a telecommunications network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé de commutation d'un terminal mobile (T) d'un premier routeur d'accès (pRA) vers un deuxième routeur d'accès (nRA), le terminal ayant établi au préalable une connexion sécurisée avec le premier routeur d'accès à laquelle est associé un contexte de communication entre le terminal et le premier routeur, ledit contexte comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, procédé dans lequel ledit contexte est transféré au deuxième routeur lors de la commutation du terminal, caractérisé en ce qu'il comprend, dans le cas où le au moins un identifiant dans le contexte transféré est déjà utilisé par ledit deuxième routeur, une étape d'envoi (320) au terminal par le deuxième routeur d'un nouvel identifiant pour ledit ensemble de paramètres de sécurité.

Description

Procédé de commutation d'un terminal mobile d'un premier routeur d'accès vers un deuxième routeur d'accès
La présente invention concerne la gestion de la sécurité lors de la commutation d'un terminal mobile d'un premier routeur d'accès, auquel le terminal est initialement connecté de manière sécurisée, vers un deuxième routeur d'accès.
Il est connu d'établir une connexion sécurisée, ou tunnel sécurisé, entre un terminal et un routeur d'accès pour sécuriser des communications établies entre ce terminal et ce routeur d'accès. Un tel tunnel peut être établi conformément au protocole de sécurité "IPsec" (pour "IP Security Protocol"). Une phase d'établissement de ce tunnel, dit "tunnel IPsec", comprend une négociation de paramètres de sécurité nécessaires à la sécurisation des communications, comme par exemple des clés qui seront utilisées pour chiffrer les communications entre les deux entités, des algorithmes cryptographiques, etc. Un protocole a été défini afin d'assurer la négociation des paramètres de sécurité lors de l'utilisation du protocole IPSec. Il s'agit du protocole IKE (pour "Internet Key Exchange") dans sa version 2, notée IKEv2. Afin de stocker et de manipuler facilement l'ensemble des paramètres de sécurité gérés par le protocole IKEv2 et utilisés par le mécanisme de sécurisation des communications, le protocole IPsec a recours à la notion d'association de sécurité (le terme couramment utilisé est le terme anglais "Security Association", connu également par son acronyme "SA"). Par définition, une association de sécurité est une structure de données qui regroupe l'ensemble des paramètres associés à une connexion sécurisée donnée entre deux pairs : les paramètres de sécurité négociés dans des échanges IKEv2 et des adresses IP de pairs source et destination impliqués dans la communication, comme le terminal et le routeur d'accès. Pour stocker l'ensemble des associations de sécurité actives à un instant donné, une base de données des associations de sécurité est utilisée (le terme couramment utilisé est le terme anglais "Security Association Database", ou "SAD"). Les éléments stockés dans la base de données SAD sont créés et modifiés par le protocole IKEv2, puis consultés par le protocole IPSec pour savoir comment traiter, en termes de sécurité, un paquet reçu, ou à émettre. Une telle base est présente sur chacun des pairs. Dans la base SAD des associations de sécurité, une association de sécurité entre le terminal et le routeur d'accès est identifiée de manière unique par un identifiant appelé index de paramètre de sécurité (le terme couramment utilisé est le terme anglais "Security Parameter Index", ou "SPI").
Au terme de la négociation IKEv2 des paramètres de sécurité, il est créé au niveau du routeur d'accès et du terminal, un contexte de communication associé à la connexion sécurisée entre le terminal et le routeur d'accès. Le contexte de communication comprend les paramètres IPsec et IKEv2 liés au terminal et au routeur d'accès : les associations de sécurité relatives aux communications entre le terminal et le routeur d'accès, leurs identifiants dans la base des associations de sécurité, ainsi qu'une politique de sécurité qui définit ce qui doit être appliqué en termes de sécurité aux paquets reçus ou à émettre. Le contexte comprend donc tous les paramètres de sécurité négociés, les adresses IP du terminal et du routeur d'accès et les identifiants des associations de sécurité, ou SPI.
Ainsi, lorsqu'un terminal mobile s'attache à un premier routeur d'accès de manière sécurisée, un premier tunnel IPsec est établi, et ce tunnel IPsec est associé à un contexte de communication comprenant au moins une association de sécurité identifiée par un index.
Lorsque ce terminal mobile se déplace d'une première zone couverte par ce premier routeur d'accès vers une deuxième zone couverte par un deuxième routeur d'accès, un deuxième tunnel IPSec doit être établi entre le terminal mobile et le deuxième routeur. L'établissement de ce deuxième tunnel IPsec nécessite de recommencer les échanges de messages IPsec depuis le début, notamment les échanges relatifs à la négociation de paramètres de sécurité. Une telle opération est consommatrice en temps. Dans le cas de services temps réel, comme par exemple un service de voix sur IP, ou un service de d'envoi de flux vidéo en mode de diffusion continu (le terme couramment utilisé est le terme anglais "streaming video"), il peut alors être difficile d'assurer une continuité du service lors de la mobilité du terminal. Pour pallier cet inconvénient, il est connu d'utiliser un mécanisme de transfert de contexte pour transférer le contexte IPSec et IKEv2 relatif au terminal mobile, du premier routeur vers le deuxième routeur. Avec le mécanisme de transfert de contexte, le contexte IPSec et IKEv2 est alors transféré du premier routeur vers le deuxième routeur lors de la mobilité du terminal. Cependant, pour que le transfert du contexte se passe correctement afin de garantir une continuité du service, certains paramètres du contexte reçu doivent être mis à jour par le deuxième routeur :
- une adresse IP du deuxième routeur d'accès vers lequel s'est effectuée la mobilité,
- une adresse IP du terminal qui, lors de son déplacement acquiert une nouvelle adresse IP,
- le cas échéant, des identifiants d'associations de sécurité entre le terminal et le routeur d'accès, s'ils sont déjà utilisés pour identifier d'autres associations de sécurité actives au niveau du deuxième routeur d'accès.
Un protocole existant, "MOBIKE" (pour "IKEv2 mobility and multihoming protocol"), est adapté pour mettre à jour et modifier des adresses IP du routeur d'accès et du terminal dans des associations de sécurité lors d'un transfert de contexte. Cependant, il n'est pas possible de mettre à jour des identifiants d'associations de sécurité dans le cas où un identifiant transféré dans un contexte lors de la mobilité d'un terminal d'un premier routeur vers un deuxième routeur est identique à un identifiant en cours d'utilisation sur le deuxième routeur. Dans un tel cas de figure, le tunnel IPSec ne peut pas bénéficier du transfert de contexte ; il doit donc être reconstruit complètement, ce qui, dans le cas de services temps réels, ne permet pas d'assurer une continuité de service.
Il existe donc un besoin pour éviter la collision d'identifiants d'association de sécurité entre un terminal et un routeur d'accès lors du transfert d'un contexte depuis un premier routeur d'accès vers un deuxième routeur d'accès au cours d'une mobilité du terminal depuis le premier routeur d'accès vers le deuxième routeur d'accès. L'invention répond à ce besoin en proposant un procédé de commutation d'un terminal mobile d'un premier routeur d'accès vers un deuxième routeur d'accès, le terminal ayant établi au préalable une connexion sécurisée avec le premier routeur d'accès à laquelle est associé un contexte de communication entre le terminal et le premier routeur, ledit contexte comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, procédé dans lequel ledit contexte est transféré au deuxième routeur lors de la commutation du terminal, caractérisé en ce qu'il comprend, dans le cas où le au moins un identifiant dans le contexte transféré est déjà utilisé par ledit deuxième routeur, une étape d'envoi au terminal par le deuxième routeur d'un nouvel identifiant pour ledit ensemble de paramètres de sécurité.
Le procédé selon l'invention permet de minimiser le temps nécessaire à la commutation d'un terminal depuis un routeur d'accès vers un deuxième routeur d'accès. En effet, il permet, lors d'un transfert de contexte et en cas de collision entre au moins un identifiant d'association de sécurité du contexte transféré avec un des identifiants déjà utilisés par le deuxième routeur pour gérer des associations de sécurité actives, de négocier un nouvel identifiant entre le terminal et le deuxième routeur. Cette négociation permet de mettre à jour les paramètres de sécurité du contexte et donc d'établir la connexion sécurisée à partir des informations du contexte mises à jour. Ainsi, il n'est pas nécessaire de renégocier depuis le début les paramètres de sécurité entre le terminal et le deuxième routeur. Il est ainsi possible de garantir une continuité de service pour des services temps réel en cours d'exécution sur le terminal mobile. Selon un mode de réalisation de l'invention, le procédé comprend, dans le cas où le nouvel identifiant reçu du deuxième routeur est déjà utilisé par le terminal, une étape d'envoi au deuxième routeur d'un autre nouvel identifiant pour ledit ensemble de paramètres de sécurité.
De façon avantageuse, un terminal qui reçoit une proposition du deuxième routeur d'accès d'un nouvel identifiant, est adapté pour envoyer au deuxième routeur une contre-proposition dans le cas ou le nouvel identifiant reçu du deuxième routeur rentre en collision avec un identifiant déjà utilisé par le terminal.
L'invention concerne aussi un signal transportant un message de notification destiné à être transmis entre un terminal et un deuxième routeur au cours d'une commutation dudit terminal depuis un premier routeur vers ledit deuxième routeur, le terminal ayant établi au préalable une connexion sécurisée avec le premier routeur d'accès à laquelle est associé un contexte de communication entre le terminal et le premier routeur, ledit contexte comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, ledit message comprenant :
- une information relative à une collision entre l'identifiant dudit contexte et un identifiant déjà utilisé par le deuxième routeur, et
- un nouvel identifiant destiné à remplacer l'identifiant du contexte. Dans une réalisation de l'invention, le message est conforme au protocole IKEv2 de type NOTIFY.
Avantageusement, le message de notification utilisé par un routeur pour proposer un nouvel identifiant à un terminal, ou par un terminal pour envoyer à un routeur une contre-proposition contenant un autre nouvel identifiant est conforme à un message existant d'un protocole normalisé. Aucun nouveau message ne nécessite ainsi d'être défini.
L'invention concerne aussi un routeur d'accès, adapté pour gérer une commutation d'un terminal mobile depuis un premier routeur d'accès vers ledit routeur d'accès, une connexion sécurisée étant établie entre le terminal et le premier routeur d'accès, à laquelle est associé un contexte de communication entre le terminal et ledit premier routeur, ledit contexte comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, ledit routeur comprenant des moyens de réception dudit contexte lors de la commutation du terminal, et étant caractérisé en ce qu'il comprend en outre :
- des moyens de détection, agencés pour détecter que le au moins un identifiant dans le contexte transféré est déjà utilisé par ledit routeur d'accès, et
- des moyens d'envoi, agencés pour envoyer au terminal un nouvel identifiant pour ledit ensemble de paramètres de sécurité dans le cas où les moyens de détection détectent que le au moins un identifiant dans le contexte transféré est déjà utilisé par ledit routeur d'accès.
L'invention concerne également un terminal mobile adapté pour commuter d'un premier routeur d'accès vers un deuxième routeur d'accès, ledit terminal étant agencé pour établir au préalable une connexion sécurisée avec le premier routeur d'accès, à laquelle est associée un contexte de communication entre le terminal et le premier routeur, ledit contexte comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, caractérisé en ce qu'il comprend : - des moyens de réception et de traitement d'un nouvel identifiant transmis par le deuxième routeur, agencés pour substituer ledit nouvel identifiant à l'identifiant relatif à l'ensemble de paramètres de sécurité dans le contexte de communication lors de la commutation du terminal vers le deuxième routeur. Dans une réalisation de l'invention, le terminal comprend en outre :
- des moyens de détection, agencés pour détecter si le nouvel identifiant reçu du deuxième routeur est déjà utilisé par le terminal, et
- des moyens de génération et d'envoi, agencés pour générer et envoyer au deuxième routeur un autre nouvel identifiant pour ledit ensemble de paramètres de sécurité, commandés par lesdits moyens de détection.
L'invention concerne aussi un programme d'ordinateur pour un routeur d'accès, comprenant :
- des instructions de code pour, en cas de transfert vers le routeur d'un contexte de communication associé à une connexion sécurisée entre un terminal et un autre routeur et comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, détecter si le au moins un identifiant du contexte transféré est déjà utilisé par ledit routeur d'accès, et
- des instructions de code pour commander l'envoi vers le terminal d'un nouvel identifiant pour ledit ensemble de paramètres de sécurité dans le cas où le au moins un identifiant du contexte transféré est déjà utilisé par ledit routeur, lorsque le programme est exécuté par un processeur. L'invention porte également sur un support de données sur lequel est enregistré le programme d'ordinateur pour un routeur d'accès selon l'invention.
L'invention concerne aussi un programme d'ordinateur pour un terminal, comprenant des instructions de code pour, en cas de transfert d'un premier routeur vers un deuxième routeur d'un contexte de communication associé à une connexion sécurisée entre le terminal et le premier routeur, la connexion sécurisée étant associée à un contexte de communication comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, remplacer ledit identifiant par un nouvel identifiant reçu en provenance du deuxième routeur, lorsque le programme est exécuté par un processeur.
L'invention porte également sur un support de données sur lequel est enregistré le programme d'ordinateur pour un terminal selon l'invention.
D'autres caractéristiques et avantages de la présente invention seront mieux compris à partir de la description d'un mode particulier de réalisation du procédé de commutation d'un terminal mobile d'un premier routeur vers un deuxième routeur selon l'invention, et des dessins annexés parmi lesquels :
- la figure 1 illustre le principe du transfert d'un contexte de communication qui est mis en œuvre par l'invention ;
- la figure 2 illustre les échanges de messages lors d'un transfert de contexte d'un premier routeur vers un deuxième routeur selon l'état antérieur de la technique ;
- la figure 3 présente les étapes du procédé de l'invention selon un mode de réalisation particulier ;
- la figure 4a, respectivement 4b est une représentation schématique d'une structure d'un message de notification selon l'état antérieur de la technique, respectivement d'un message de notification selon un mode particulier de réalisation de l'invention ; - la figure 5 est une représentation bloc fonctionnel d'un routeur d'accès selon un mode de réalisation de l'invention ; - la figure 6 est une représentation bloc fonctionnel d'un terminal selon un mode de réalisation de l'invention.
La figure 1 illustre un principe mis en œuvre par le procédé de l'invention. Un terminal mobile T, attaché à un routeur d'accès pRA accède au réseau Internet de manière sécurisée. A cette fin, le terminal T a établi une connexion sécurisée avec le routeur d'accès pRA, représentée sur la figure par un tunnel pT entre le terminal T et le routeur d'accès pRA. La connexion sécurisée est établie conformément au protocole "IPsec" (pour "IP security protocol"), par exemple selon un mode dit "mode tunnel". Le tunnel pT, dit "tunnel IPsec" permet de sécuriser les communications entre le terminal mobile T et le routeur d'accès pRA. Des échanges protocolaires sont nécessaires pour établir le tunnel IPsec, ils comprennent de premiers échanges permettant de négocier des paramètres de sécurité qui sont utilisés pour sécuriser les communications entre le terminal mobile T et le routeur d'accès pRA. Les premiers échanges qui permettent de négocier les paramètres de sécurité sont conformes, par exemple au protocole "IKE" (pour "Internet Key Exchange") dans sa version 2, notée "IKEv2". Les paramètres négociés lors des échanges IKEv2 sont par exemple des algorithmes cryptographiques, des clés de chiffrement, un mode, par exemple le mode tunnel, à utiliser pour sécuriser les communications entre pairs, tels que le terminal T et le routeur d'accès pRA. C'est également au cours des échanges IKEv2 que des structures de données appelées "associations de sécurité" (le terme couramment utilisé est le terme anglais "Security Association") sont définies. Une association de sécurité est une structure de données qui regroupe l'ensemble des paramètres associés à une connexion sécurisée donnée entre deux pairs : les paramètres de sécurité négociés dans des échanges IKEv2, et les adresses IP des pairs respectivement source et destination. Au cours des échanges IKEv2, deux types d'association de sécurité sont créées : - des associations de sécurité utilisées par le protocole IPsec, une fois le tunnel sécurisé établi, pour sécuriser les communications entre pairs ; on note par la suite ces associations de sécurité les "associations de sécurité IPsec", - des associations de sécurité utilisées par le protocole IKEv2 pour protéger la négociation des associations de sécurité IPsec ; on note par la suite ces associations de sécurité les "associations de sécurité IKE".
Les associations de sécurité sont stockées dans des bases de données non représentées, au niveau du terminal T et du routeur d'accès pRA. Les bases de données sont appelées bases de données des associations de sécurité (le terme couramment utilisé est le terme anglais "Security Association Database", notée également "SAD"). Dans ces bases de données, chaque association de sécurité est identifiée de façon unique par un identifiant appelé index de paramètre de sécurité (le terme couramment utilisé est le terme anglais "Security Parameter Index", ou "SPI"). On notera qu'une association de sécurité est directionnelle : pour un pair donné, une association de sécurité est appliquée à une réception de paquets par ce pair, et une autre association de sécurité est appliquée à une émission de paquets par ce pair. Au terme de la négociation IKEv2 des paramètres de sécurité, il est créé au niveau du routeur d'accès pRA et du terminal T, un contexte de communication associé au tunnel sécurisé pT. Le contexte de communication comprend des paramètres IPsec et IKEv2 liés au terminal T et au routeur d'accès pRA, et plus précisément : - les associations de sécurité relatives aux communications entre le terminal et le routeur d'accès,
- les identifiants de ces associations de sécurité, ainsi que
- une politique de sécurité qui définit ce qui doit être appliqué en termes de sécurité aux paquets reçus ou à émettre. Prenons l'exemple du terminal mobile T qui, lors d'un déplacement, détecte un deuxième routeur d'accès nRA. Le terminal mobile T décide, en fonction de critères qui lui sont propres d'accéder au réseau via le deuxième routeur d'accès nRA. A cette fin, le terminal T doit d'une part se détacher du routeur pRA grâce auquel il accédait au réseau jusqu'à présent, et d'autre part s'attacher au deuxième routeur nRA. On dit que le terminal T effectue une commutation du routeur pRA vers le deuxième routeur nRA. Pour accéder au réseau via le deuxième routeur nRA de manière sécurisée, le terminal T doit établir une connexion sécurisée avec le deuxième routeur d'accès nRA. Cette connexion est représentée par un tunnel nT. Afin de limiter les échanges protocolaires entre le terminal mobile T et le deuxième routeur d'accès nRA lors de l'établissement de la connexion sécurisée entre ces deux pairs, il est transféré un contexte comprenant des paramètres IKEv2 et IPSec liés au terminal T et au premier routeur d'accès pRA. Le contexte transféré comprend les associations de sécurité relatives aux communications entre le terminal T et le premier routeur d'accès pRA, les identifiants de ces associations de sécurité, ainsi qu'une politique de sécurité qui définit ce qui doit être appliqué en termes de sécurité aux paquets reçus ou à émettre.
Le transfert de contexte du premier routeur pRA vers le deuxième routeur nRA est schématisé par une flèche pointillée du routeur pRA vers le deuxième routeur nRA. Ce transfert de contexte entre routeurs d'accès permet d'établir une connexion sécurisée entre le terminal T et le deuxième routeur nRA en s'affranchissant d'une négociation complète entre le terminal T et le deuxième routeur nRA, notamment de la négociation des paramètres de sécurité effectuée au moyen du protocole IKEv2. Le contexte qui est transféré du routeur pRA au deuxième routeur nRA est ensuite activé sur le deuxième routeur nRA. Cette activation correspond à la mise en place du contexte sur le deuxième routeur nRA. Le deuxième routeur nRA traite alors le contexte. En particulier, le contexte est mis à jour par le deuxième routeur nRA :
- une nouvelle adresse IP du terminal T est précisée, dans la mesure où celui-ci, en se déplaçant, a acquis une nouvelle adresse IP,
- une adresse IP du routeur d'accès auquel est attaché le terminal T est mise à jour avec l'adresse du deuxième routeur d'accès nRA,
- le cas échéant et selon l'invention, il y a une mise à jour d'identifiants d'associations de sécurité utilisés pour identifier de manière unique des associations de sécurité entre le terminal et le routeur d'accès, si ces identifiants sont déjà utilisés pour identifier d'autres associations de sécurité actives au niveau du deuxième routeur nRA. Le procédé pour mettre à jour les identifiants d'associations de sécurité est décrit en relation avec la figure 3. Un protocole existant, "MOBIKE" ("IKEv2 mobility and multihoming protocol") est utilisé pour mettre à jour les adresses IP du routeur et du terminal.
Le transfert de contexte permet de transférer du routeur pRA vers le deuxième routeur nRA des informations pertinentes et immédiatement réutilisables par le deuxième routeur nRA. Il résulte du transfert de contexte un gain de temps lors de la commutation du terminal T du routeur pRA vers le deuxième routeur nRA.
Dans un cas, non représenté, où le transfert de contexte du premier routeur pRA vers le deuxième routeur d'accès nRA n'est pas utilisé, il est nécessaire pour l'établissement de la connexion sécurisée entre le terminal mobile T et le deuxième routeur d'accès nRA, de recommencer les échanges protocolaires IKEv2 et IPSec depuis le début afin de reconstruire depuis le début le tunnel sécurisé.
Les étapes relatives à une commutation d'un terminal mobile, en déplacement, depuis un routeur d'accès vers un deuxième routeur d'accès selon l'état antérieur de la technique vont maintenant être décrites en relation avec la figure 2.
Dans une étape initiale 20 au cours de laquelle le terminal mobile T s'attache au routeur d'accès pRA, il est négocié des paramètres de sécurité entre le terminal T et le routeur pRA pour établir une connexion sécurisée avec le routeur d'accès pRA. La négociation se déroule au moyen d'échanges de messages, non détaillés, conformes au protocole IKEv2.
A la fin de cette négociation, un contexte de communication, non représenté, est disponible au niveau du terminal mobile T et du premier routeur d'accès pRA. Le contexte comprend les associations de sécurité IPsec et IKEv2 associées aux connexions sécurisées entre le terminal T et le routeur pRA, les identifiants des associations de sécurité, et une politique de sécurité qui définit comment traiter, en termes de sécurité, des paquets reçus ou à émettre. Ainsi, le contexte de communication entre le terminal T et le routeur d'accès pRA comprend les paramètres de sécurité nécessaires à la sécurisation des communications entre le terminal T et le routeur d'accès pRA, les adresses IP du terminal T et du routeur d'accès pRA, et les identifiants, ou SPI, des associations de sécurité dans la base des associations de sécurité SAD.
Au terme de l'étape initiale 20, la connexion sécurisée est établie entre le terminal T et le routeur pRA au moyen d'un tunnel IPsec t20. Dans une étape 21 de transfert de contexte, au cours de laquelle le terminal mobile T effectue une mobilité vers le deuxième routeur d'accès nRA, le contexte de communication établi au cours de l'étape 20 est transféré du routeur d'accès pRA au deuxième routeur d'accès nRA. Le transfert s'effectue au moyen d'échanges de messages, non détaillés, conformes au protocole "CXTP" (de l'anglais "Context Transfer Protocol") entre le routeur pRA, le deuxième routeur nRA et le terminal T. Les messages échangés pour transférer le contexte de communication du routeur pRA au routeur nRA étant connus de l'homme du métier et ne faisant pas partie de l'invention, ils ne seront pas décrits davantage dans la présente description. Les associations de sécurité sont mises à jour dans les bases de données des associations de sécurité du terminal T et du deuxième routeur d'accès nRA. Dans une sous-étape d'attachement 210, consécutive à la réception d'un message de requête d'activation de transfert CTAR2, le terminal T s'attache au deuxième routeur d'accès nRA. On suppose ici que le deuxième routeur d'accès nRA détecte une collision entre au moins un des identifiants d'associations de sécurité reçus dans le contexte et un des identifiants d'associations de sécurité qu'il utilise déjà lui-même.
Dans une étape 22 d'attachement du terminal T au deuxième routeur d'accès nRA, comparable à l'étape initiale 20, des paramètres de sécurité sont renégociés entre le terminal T et le deuxième routeur d'accès nRA. Au terme de l'étape d'attachement 22, une connexion sécurisée est établie entre le terminal T et le deuxième routeur d'accès nRA. Elle est représentée par un nouveau tunnel t22. On remarquera que, dans l'art antérieur, l'établissement du nouveau tunnel t22 nécessite de recommencer les échanges protocolaires IKEv2 depuis le début. Dans un cas, non représenté, correspondant au cas où aucune collision entre identifiants d'associations de sécurité n'est détectée par le deuxième routeur d'accès nRA dans la sous-étape d'attachement 210, alors, le deuxième routeur d'accès nRA active le contexte reçu et le traite. On considère à cet instant que l'ancien tunnel qui sécurisait les communications entre le terminal T et le routeur pRA a été transféré entre le terminal T et le deuxième routeur d'accès nRA. Cependant, le contexte associé au tunnel transféré n'a pas encore été mis à jour. Dans une étape suivante de mise à jour, le deuxième routeur nRA met à jour le contexte de communication associé à la communication entre le terminal T et le routeur nRA. A cette fin, des messages conformes au protocole MOBIKE sont échangés entre le deuxième routeur nRA et le terminal T afin de mettre à jour les adresses IP du terminal T et du deuxième routeur nRA dans les associations de sécurité. La connexion sécurisée entre le terminal T et le deuxième routeur nRA est alors établie.
Les étapes relatives à une commutation d'un terminal mobile en déplacement depuis un routeur d'accès vers un deuxième routeur d'accès selon un mode de réalisation particulier de l'invention vont maintenant être décrites en relation avec la figure 3. Dans une étape initiale 30, comparable à l'étape 20 selon la figure 2, le terminal mobile T s'attache au routeur d'accès pRA. Il y a négociation de paramètres de sécurité pour établir la connexion sécurisée entre le terminal T et le routeur d'accès pRA. En fin d'étape 30, le contexte de communication associé à la connexion sécurisée entre les deux pairs est défini au niveau du terminal mobile T et du routeur d'accès pRA.
Au terme de l'étape initiale 30, la connexion sécurisée est établie entre le terminal T et le routeur pRA au moyen d'un tunnel IPsec t30.
Suite à une mobilité du terminal mobile T vers le deuxième routeur d'accès nRA, dans une étape 31 de transfert de contexte, il est transféré, du routeur d'accès pRA au deuxième routeur d'accès nRA, le contexte de communication établi au cours de l'étape 30. Dans une sous-étape d'attachement 310, analogue à la sous-étape d'attachement 210 selon la figure 2, et consécutive à la réception d'un message de requête d'activation de transfert CTAR2, le terminal T s'attache au deuxième routeur d'accès nRA. Le deuxième routeur d'accès nRA détecte une collision entre au moins un des identifiants d'association de sécurité reçus dans le contexte de communication, et un des identifiants d'association de sécurité qu'il utilise déjà. La collision peut concerner un ou plusieurs identifiants. Les identifiants qu'il utilise déjà correspondent, par exemple, à des connexions sécurisées qu'il a établies avec d'autres terminaux non représentés. Dans une sous-étape 311 d'activation de contexte, le deuxième routeur nRA active le contexte reçu et commence à le traiter.
On considère à cet instant que l'ancien tunnel IPsec t30 qui sécurisait les communications entre le terminal T et le routeur d'accès pRA a été transféré entre le terminal T et le deuxième routeur d'accès nRA. Ce tunnel est représenté par un ancien tunnel transféré 131. Cependant, le contexte associé à l'ancien tunnel transféré t31 n'a pas encore été mis à jour.
Dans une étape de mise à jour 32, le deuxième routeur d'accès nRA met à jour le contexte de communication associé à la connexion sécurisée entre le terminal T et le deuxième routeur d'accès nRA. A cette fin, des messages conformes au protocole MOBIKE sont échangés entre le deuxième routeur nRA et le terminal T afin de mettre à jour les adresses IP du terminal T et du deuxième routeur d'accès nRA dans les associations de sécurité associées à la connexion sécurisée et, selon l'invention, afin de négocier de nouveaux identifiants d'associations de sécurité entre le terminal et le routeur d'accès nRA, en remplacement du ou des identifiants pour lesquels une collision a été détectée. La négociation de nouveaux identifiants a pour but de trouver des identifiants d'associations de sécurité pour la communication sécurisée entre le terminal et le routeur d'accès nRA qui ne sont pas déjà utilisés par le deuxième routeur d'accès nRA et, le cas échéant, par le terminal T. A cette fin, dans une sous-étape 320 d'envoi d'un nouvel identifiant, un message m32-1 de type "INFORMATIONAL" transportant au moins une donnée de type notification est envoyé. Le message m32-1 transporte une notification de mise à jour des adresses IP des pairs, notée "N(UPDATE_SA_ADDRESSES)" et autant de notifications selon l'invention, notées "N(UPDATE_SPI)" et comprenant chacune un nouvel identifiant d'association de sécurité, que d'identifiants détectés comme déjà utilisés au cours de la sous-étape d'attachement 310. La donnée de type notification selon l'invention est décrite en relation avec la figure 4b.
Dans une sous-étape 321 optionnelle d'envoi d'un autre nouvel identifiant, le terminal T qui reçoit une proposition d'au moins un identifiant d'association de sécurité dans le message m32-1 , détecte une collision entre l'identifiant reçu du deuxième routeur d'accès nRA et un identifiant d'association de sécurité qu'il utilise déjà pour gérer une connexion sécurisée avec un autre pair non représenté. Le terminal envoie alors dans un message m32-2 selon l'invention une proposition d'un autre nouvel identifiant. On notera que la proposition concerne un ou plusieurs identifiants selon qu'il y a collision avec un ou plusieurs identifiants gérés par le terminal T. Dans une sous-étape 322 optionnelle, correspondant au cas où une collision entre identifiants serait encore détectée par le deuxième routeur d'accès nRA à la réception du message m32-1 , celui-ci envoie une proposition d'au moins un identifiant d'association de sécurité dans un message m32-3.
Le cas échéant, des envois de proposition, non représentés, de nouveaux identifiants entre le terminal T et le deuxième routeur d'accès nRA continuent jusqu'à ce qu'il n'y ait plus de collision entre identifiants proposés et identifiants déjà utilisés, ou jusqu'à ce qu'une temporisation expire. Dans ce dernier cas, un tunnel sécurisé est reconstruit complètement, il y a renégociation des paramètres de sécurité depuis le départ. En fin d'étape 32, la négociation d'identifiants entre le deuxième routeur d'accès nRA et le terminal T s'est terminée avec succès. Il a été trouvé de nouveaux identifiants pour les associations de sécurité transférées dans le contexte. La communication sécurisée entre le terminal T et le deuxième routeur nRA est établie, ce qui est représenté sur la figure par un tunnel t32.
Un message selon l'invention, utilisé pour proposer de nouveaux identifiants d'associations de sécurité en cas de collision détectée par le deuxième routeur nRA lors d'un transfert de contexte depuis le routeur d'accès pRA va maintenant être décrit en relation avec les figures 4a et 4b.
La figure 4a est une représentation d'un message conforme au protocole
IKEv2 de type INFORMATIONAL contenant une donnée de type NOTIFY. Un tel message est habituellement utilisé au cours d'échanges conformes au protocole MOBIKE pour transmettre un message relativement à une erreur ou à une notification. Il peut par exemple être transmis un tel message pour notifier à un pair destinataire une nouvelle adresse IP du pair émetteur. Dans ce dernier cas, la notification transmise utilise un type "UPDATE_SA_ADDRESSES". Dans le message de notification selon la figure 4a, si le message concerne une association de sécurité existante, alors le champ "Protocol ID" précise le type de l'association de sécurité : IKE ou IPsec.
Le champ "SPI size" précise la longueur de l'identifiant SPI ou zéro.
Le champ "Notify Message Type" précise le type du message de notification. Par exemple, "UPDATE_SA_ADDRESSES".
Le champ "Security Parameter Index" contient l'identifiant SPI.
Et enfin, le champ "Notification Data" précise la donnée informationnelle, ou l'erreur transmise en plus du "Notify Message Type".
Dans un message selon l'invention, et décrit en relation avec la figure 4b, il est défini un nouveau type de notification adapté pour permettre à un pair de proposer un nouvel identifiant d'association de sécurité lorsque ce pair détecte une collision entre un identifiant qu'il utilise déjà et un identifiant d'association de sécurité qu'il reçoit. La détection d'une collision entre identifiants peut avoir lieu lors d'un transfert de contexte depuis un routeur d'accès vers un deuxième routeur d'accès. Dans un autre cas, la détection peut avoir lieu suite à la réception d'un message contenant une proposition d'un nouvel identifiant selon l'invention.
Le message selon l'invention est comparable à un message de notification tel que décrit en relation avec la figure 4a. Selon l'invention, un nouveau type "UPDATE_SPI" permet de caractériser le type de la notification.
Un message de type "UPDATE_SPI" est adapté pour proposer un nouvel identifiant d'association de sécurité en remplacement d'un identifiant déjà utilisé. Le champ "Security Parameter Index" comprend l'identifiant SPI à remplacer.
Le champ "New Security Parameter Index" comprend le nouvel identifiant, généré pour éviter la collision avec l'identifiant du champ "Security Parameter Index".
Un drapeau "D" de direction permet de préciser si l'identifiant à modifier est côté terminal, ou côté routeur d'accès. Par exemple, le drapeau est codé sur un bit et vaut "O" s'il est côté terminal, et "1 " s'il est côté routeur d'accès.
Si une collision est détectée pour plusieurs identifiants d'association de sécurité, alors le message IKEv2 comprend plusieurs notifications de type "UPDATE_SPI".
Un routeur d'accès selon l'invention va maintenant être décrit en relation avec la figure 5. Un routeur d'accès 50 selon l'invention assure une fonction de base d'un routeur : le routage de paquets. En tant que routeur d'accès, il permet à un terminal d'accéder à un ou plusieurs réseaux. De manière classique, il est adapté pour établir une connexion sécurisée avec le terminal qui s'attache à lui pour accéder au réseau. Par exemple, les connexions sécurisées sont établies au moyen du protocole IPsec. Le routeur 50 selon l'invention est adapté pour recevoir et transmettre à d'autres routeurs des contextes de communication, associés à des connexions sécurisées établies avec des pairs tels que des terminaux. Il est en outre adapté pour négocier avec ces pairs de nouveaux identifiants d'associations de sécurité associées aux connexions sécurisées lorsqu'il détecte des collisions entre au moins un identifiant présent dans un contexte qu'il reçoit, et un des identifiants qu'il utilise déjà pour gérer d'autres connexions sécurisées avec d'autres pairs. Il est également agencé pour recevoir et traiter des propositions de nouveaux identifiants d'association de sécurité de terminaux qui s'attachent à lui. Le routeur d'accès 50 comprend plusieurs modules : des interfaces réseau 51 , une mémoire 52, un module 53 de réception et de transfert de contexte, un module de détection 54, un module 55 d'envoi et de réception d'une proposition d'au moins un nouvel identifiant d'association de sécurité, un module de génération 56 et des bases de données 57. Les modules 51 , 52, 53, 54, 55, 56 et 57 sont reliés à un microprocesseur 58 :
- les interfaces réseau 51 permettent d'une part à un terminal ou à un autre routeur d'accès de communiquer avec le routeur d'accès 50 selon différentes technologies, par exemple selon un mode WiFi, WiMax, et elles permettent d'autre part au routeur d'accès 50 d'accéder à un ou plusieurs réseaux, par exemple le réseau Internet et de fournir ainsi l'accès au réseau au terminal ou routeur qui s'est attaché à lui ; - les bases de données 57 sont créées dynamiquement lors de l'établissement des connexions sécurisées entre le routeur et des pairs. Ces bases comprennent la base SAD des associations de sécurité et une base de politique de sécurité (le terme couramment utilisé est le terme anglais "Security Poiicy Database", ou "SPD") qui définit ce qui doit être appliqué, en termes de sécurité, aux paquets reçus ou à émettre.
- la mémoire 52 permet d'effectuer des calculs, de gérer les bases de données 57, de charger des instructions logicielles correspondant aux étapes du procédé de gestion de la commutation décrite précédemment, et de les faire exécuter par le microprocesseur 58 ; - le microprocesseur 58, ou "CPU" (de l'anglais "Central Processing
Unit") est une unité de traitement ;
- un module 53 de réception et de transfert de contexte, agencé pour recevoir d'un autre routeur d'accès un contexte associé à une communication sécurisée établie préalablement entre l'autre routeur d'accès et le terminal, et pour transférer un contexte associé à une communication sécurisée vers un autre routeur ;
- un module de détection 54, agencé pour détecter des collisions entre au moins un des identifiants d'association de sécurité reçus lors du transfert d'un contexte associé à un terminal depuis un autre routeur, et un des identifiants d'associations de sécurité qu'il utilise déjà, par exemple dans le cadre de communications sécurisées déjà établies avec un autre terminal ; - un module 55 d'envoi et de réception d'au moins une proposition de nouvel identifiant ;
- un module de génération 56, agencé pour générer au moins un nouvel identifiant dans le cas où le module de détection 54 détecte une collision entre au moins un identifiant qu'il reçoit dans un contexte qui lui est transféré par un autre routeur ou entre au moins un identifiant qu'il reçoit d'un terminal dans une proposition d'identifiant, et au moins un identifiant qu'il utilise déjà. Il est agencé également pour générer une proposition relative à ce au moins un nouvel identifiant. Les modules 55 d'envoi et de réception, et le module de génération 56 coopèrent pour envoyer un nouvel identifiant d'association de sécurité lorsqu'une collision a été détectée par le module de détection 54.
Les modules 53, 54, 55 et 56 sont agencés pour mettre en œuvre celles des étapes du procédé de commutation précédemment décrit qui sont mises en œuvre par le routeur d'accès. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé de commutation précédemment décrit, mises en œuvre par un processeur d'un routeur d'accès.
L'invention concerne donc aussi : - un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de commutation tel que décrit précédemment lorsque ce programme est exécuté par un processeur ;
- un support d'enregistrement lisible par un routeur d'accès sur lequel est enregistré le programme d'ordinateur décrit ci-dessus. Les modules logiciels peuvent être stockés dans, ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal ou un réseau de télécommunication.
Un terminal mobile selon l'invention va maintenant être décrit en relation avec la figure 6. Un terminal mobile 60 selon l'invention possède des fonctions classiques d'accès à un réseau, par exemple le réseau Internet, par attachement à un routeur d'accès. De manière classique, le terminal mobile 60 est agencé pour établir une connexion sécurisée avec un routeur d'accès auquel il s'attache. Le terminal mobile 60 comprend plusieurs modules : des interfaces réseau 61 , une mémoire 62, un module 63 de réception et de traitement d'un nouvel identifiant d'association de sécurité, un module 64 de génération et d'envoi d'un nouvel identifiant d'association de sécurité, un module 65 de détection et des bases de données 66. Les modules 61 , 62, 63, 64, 65 et 66 sont reliés à un microprocesseur 67 :
- les interfaces réseau 61 sont adaptées pour accéder à un réseau par attachement à des routeurs d'accès et pour détecter la présence de routeurs d'accès dans une zone géographique. L'attachement à un routeur d'accès peut se faire selon différentes technologies, par exemple selon un mode WiFi ; - les bases de données 66 sont créées dynamiquement lors de l'établissement des connexions sécurisées entre le terminal et des routeurs. Ces bases comprennent la base SAD des associations de sécurité et une base SPD de politique de sécurité qui définit ce qui doit être appliqué, en termes de sécurité, aux paquets reçus ou à émettre. - la mémoire 62 permet d'effectuer des calculs, de gérer les bases de données 66, de charger des instructions logicielles correspondant aux étapes du procédé de traitement d'un nouvel identifiant par le terminal mobile décrit précédemment, et de les faire exécuter par le microprocesseur 67 ;
- le microprocesseur 67, ou "CPU" est une unité de traitement ; - le module 63 de réception et de traitement d'un nouvel identifiant est agencé pour, lors de la commutation du terminal d'un premier routeur vers un deuxième routeur et dans le cas où une collision entre identifiants d'associations de sécurité relatives à un ensemble de paramètres de sécurité est détectée, recevoir un nouvel identifiant transmis par ce deuxième routeur et le substituer à un identifiant utilisé par le terminal pour une association de sécurité dans la base des associations de sécurité ; - le module 64 de génération et d'envoi de nouvel identifiant est agencé pour générer et envoyer, le cas échéant, un nouvel identifiant au routeur d'accès dans le cas où l'identifiant reçu du routeur d'accès est déjà utilisé par le terminal pour identifier une association de sécurité active. - le module 65 de détection est agencé pour détecter, lors de la réception d'un identifiant d'association de sécurité envoyé par un routeur d'accès, que l'identifiant est déjà utilisé par le terminal pour identifier une association de sécurité active ;
Les modules 63, 64 et 65 sont agencés pour mettre en œuvre celles des étapes précédemment décrites du procédé de commutation qui sont mises en œuvre par le terminal mobile. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé de commutation d'un terminal mobile par le terminal.
L'invention concerne donc aussi : - un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de commutation d'un terminal tel que décrit précédemment lorsque ce programme est exécuté par un processeur ;
- un support d'enregistrement lisible par un nœud sur lequel est enregistré le programme d'ordinateur décrit ci-dessus. Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal, ou un réseau de télécommunication.

Claims

REVENDICATIONS
1. Procédé de commutation d'un terminal mobile (T) d'un premier routeur d'accès (pRA) vers un deuxième routeur d'accès (nRA), le terminal ayant établi au préalable une connexion sécurisée avec le premier routeur d'accès à laquelle est associé un contexte de communication entre le terminal et le premier routeur, ledit contexte comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, procédé dans lequel ledit contexte est transféré au deuxième routeur lors de la commutation du terminal, caractérisé en ce qu'il comprend, dans le cas où le au moins un identifiant dans le contexte transféré est déjà utilisé par ledit deuxième routeur, une étape d'envoi (320) au terminal par le deuxième routeur d'un nouvel identifiant pour ledit ensemble de paramètres de sécurité.
2. Procédé selon la revendication 1 , comprenant dans le cas où le nouvel identifiant reçu du deuxième routeur est déjà utilisé par le terminal :
- une étape d'envoi (321 ) au deuxième routeur d'un autre nouvel identifiant pour ledit ensemble de paramètres de sécurité.
3. Signal transportant un message de notification destiné à être transmis entre un terminal (T) et un deuxième routeur (nRA) au cours d'une commutation dudit terminal depuis un premier routeur (pRA) vers ledit deuxième routeur, le terminal ayant établi au préalable une connexion sécurisée avec le premier routeur d'accès à laquelle est associé un contexte de communication entre le terminal et le premier routeur, ledit contexte comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, ledit message comprenant :
- une information relative à une collision entre l'identifiant dudit contexte et un identifiant déjà utilisé par le deuxième routeur, et
- un nouvel identifiant destiné à remplacer l'identifiant du contexte.
4. Message selon la revendication 3 caractérisé en ce qu'il s'agit d'un message conforme au protocole IKEv2 de type NOTIFY.
5. Routeur d'accès (50), adapté pour gérer une commutation d'un terminal mobile depuis un premier routeur d'accès vers ledit routeur d'accès, une connexion sécurisée étant établie entre le terminal et le premier routeur d'accès, à laquelle est associé un contexte de communication entre le terminal et ledit premier routeur, ledit contexte comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, ledit routeur comprenant des moyens (53) de réception dudit contexte lors de la commutation du terminal, et étant caractérisé en ce qu'il comprend en outre :
- des moyens (54) de détection, agencés pour détecter que le au moins un identifiant dans le contexte transféré est déjà utilisé par ledit routeur d'accès, et - des moyens d'envoi (55), agencés pour envoyer au terminal un nouvel identifiant pour ledit ensemble de paramètres de sécurité dans le cas où les moyens de détection détectent que le au moins un identifiant dans le contexte transféré est déjà utilisé par ledit routeur d'accès.
6. Terminal mobile (60) adapté pour commuter d'un premier routeur d'accès vers un deuxième routeur d'accès, ledit terminal étant agencé pour établir au préalable une connexion sécurisée avec le premier routeur d'accès, à laquelle est associée un contexte de communication entre le terminal et le premier routeur, ledit contexte comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, caractérisé en ce qu'il comprend :
- des moyens (63) de réception et de traitement d'un nouvel identifiant transmis par le deuxième routeur, agencés pour substituer ledit nouvel identifiant à l'identifiant relatif à l'ensemble de paramètres de sécurité dans le contexte de communication lors de la commutation du terminal vers le deuxième routeur.
7. Terminal (60) selon la revendication 6, comprenant en outre :
- des moyens de détection (65), agencés pour détecter si le nouvel identifiant reçu du deuxième routeur est déjà utilisé par le terminal, et
- des moyens (64) de génération et d'envoi, agencés pour générer et envoyer au deuxième routeur un autre nouvel identifiant pour ledit ensemble de paramètres de sécurité, commandés par lesdits moyens de détection (65).
8. Produit programme d'ordinateur pour un routeur d'accès, comprenant des instructions de code de programme enregistrées sur un support lisible par un ordinateur, comprenant :
- des moyens de programmation lisibles par ordinateur pour, en cas de transfert vers le routeur d'un contexte de communication associé à une connexion sécurisée entre un terminal et un autre routeur et comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, détecter si le au moins un identifiant du contexte transféré est déjà utilisé par ledit routeur d'accès, et
- des moyens de programmation lisibles par ordinateur pour commander l'envoi vers le terminal d'un nouvel identifiant pour ledit ensemble de paramètres de sécurité dans le cas où le au moins un identifiant du contexte transféré est déjà utilisé par ledit routeur, lorsque ledit programme fonctionne sur un ordinateur.
9. Support de données sur lequel est enregistré le produit programme d'ordinateur selon la revendication 8.
10. Produit programme d'ordinateur pour un terminal, comprenant des instructions de code de programme enregistrées sur un support lisible par un ordinateur, comprenant des moyens de programmation lisibles par un ordinateur pour, en cas de transfert d'un premier routeur vers un deuxième routeur d'un contexte de communication associé à une connexion sécurisée entre le terminal et le premier routeur, la connexion sécurisée étant associée à un contexte de communication comprenant au moins un identifiant relatif à un ensemble de paramètres de sécurité de la connexion, remplacer ledit identifiant par un nouvel identifiant reçu en provenance du deuxième routeur, lorsque ledit programme fonctionne sur un ordinateur.
11. Support de données sur lequel est enregistré le produit programme d'ordinateur selon la revendication 10.
EP09730543A 2008-03-31 2009-03-30 Procede de commutation d'un terminal mobile d'un premier routeur d'acces vers un deuxieme routeur d'acces Withdrawn EP2266286A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0852092 2008-03-31
PCT/FR2009/050539 WO2009125153A2 (fr) 2008-03-31 2009-03-30 Procede de commutation d'un terminal mobile d'un premier routeur d'acces vers un deuxieme routeur d'acces

Publications (1)

Publication Number Publication Date
EP2266286A2 true EP2266286A2 (fr) 2010-12-29

Family

ID=39941877

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09730543A Withdrawn EP2266286A2 (fr) 2008-03-31 2009-03-30 Procede de commutation d'un terminal mobile d'un premier routeur d'acces vers un deuxieme routeur d'acces

Country Status (3)

Country Link
US (1) US20110067089A1 (fr)
EP (1) EP2266286A2 (fr)
WO (1) WO2009125153A2 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110302416A1 (en) * 2010-03-15 2011-12-08 Bigband Networks Inc. Method and system for secured communication in a non-ctms environment
CN102065428B (zh) * 2010-12-28 2013-06-12 广州杰赛科技股份有限公司 一种安全的无线城域网的用户终端切换方法
CN103731407B (zh) * 2012-10-12 2017-08-11 华为技术有限公司 Ike报文协商的方法及系统
US10116754B2 (en) * 2014-01-30 2018-10-30 Comcast Cable Communications, Llc Dynamic configuration of interface identifiers
US10848524B2 (en) 2018-02-23 2020-11-24 Cisco Technology, Inc. On-demand security association management

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6823461B2 (en) * 2002-06-27 2004-11-23 Nokia Corporation Method and system for securely transferring context updates towards a mobile node in a wireless network
US8186026B2 (en) * 2004-03-03 2012-05-29 Rockstar Bidco, LP Technique for maintaining secure network connections
US20050273853A1 (en) * 2004-05-24 2005-12-08 Toshiba America Research, Inc. Quarantine networking
US8230212B2 (en) * 2006-08-29 2012-07-24 Alcatel Lucent Method of indexing security keys for mobile internet protocol authentication

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2009125153A2 *

Also Published As

Publication number Publication date
US20110067089A1 (en) 2011-03-17
WO2009125153A3 (fr) 2009-12-03
WO2009125153A2 (fr) 2009-10-15

Similar Documents

Publication Publication Date Title
US10389831B2 (en) Method, apparatus and system for provisioning a push notification session
USRE46113E1 (en) Technique for maintaining secure network connections
JP4245838B2 (ja) セキュアクライアントサーバトランザクションを管理するための方法及びシステム
EP3871361B1 (fr) Remise à la clé d'une association de sécurité sa
US11943209B2 (en) Rekeying a security association SA
CN116016633B (zh) 通信建立方法及系统
JP2012518302A (ja) 非暗号化ネットワーク動作解決策
EP2266286A2 (fr) Procede de commutation d'un terminal mobile d'un premier routeur d'acces vers un deuxieme routeur d'acces
JP2016532398A (ja) Ｔｌｓプロトコル拡張
EP4222994A1 (fr) Procedes de configuration d'un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d'une connexion, et dispositifs associes
JP2011176395A (ja) ＩＰｓｅｃ通信方法およびＩＰｓｅｃ通信システム
EP2156600B1 (fr) Procédé de distribution de clé d'authentification, terminal, serveur de mobilité et programmes d'ordinateurs correspondants
CN110365570B (zh) IPSec流量转发方法、装置、电子设备
CN118074968A (zh) 一种IPSec VPN建立方法及装置
CN121444393A (zh) 边缘连接网关
EP4133707A1 (fr) Procede mis en oeuvre par une entite intermediaire pour gerer une communication entre deux dispositifs de communication
WO2008087355A2 (fr) Procede d'itinerance dans un reseau sans fil
EP3348090B1 (fr) Procédé et dispositif d'établissement et de maintien d'un accès à internet par utilisation d'un protocole de communication sans fil en réseau informatique local à partir d'une station cliente mobile
EP2469959B1 (fr) Procédé et dispositif de gestion d´une session de communication entre un terminal multi-accès et un serveur ANDSF
CN121792103A (zh) 一种适用于sdwan的无延迟热备份方法、系统及设备

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20101026

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA RS

RIN1 Information on inventor provided before grant (corrected)

Inventor name: COMBES, JEAN-MICHEL

Inventor name: BOURNELLE, JULIEN

Inventor name: ALLARD, FABIEN

RIN1 Information on inventor provided before grant (corrected)

Inventor name: COMBES, JEAN-MICHEL

Inventor name: BOURNELLE, JULIEN

Inventor name: ALLARD, FABIEN

DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIN1 Information on inventor provided before grant (corrected)

Inventor name: COMBES, JEAN-MICHEL

Inventor name: BOURNELLE, JULIEN

Inventor name: ALLARD, FABIEN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20120110