Patent Publication Number: US-2011055551-A1

Title: Method and network nodes for generating cryptographically generated addresses in mobile ip networks

Description:
FIELD 
     The present invention generally relates to mobile IP networks. More specifically, the present invention is concerned with a method and network nodes for cryptographically generating addresses in mobile IP networks. 
     BACKGROUND 
     Over the past few decades, telecommunications and Internet have experienced an incredible growth and expansion. Technologies have changed from centralized computing to personalized computing and now to mobile computing with a convergence of networks, devices and services. 
     Mobile computing is made possible through the use of Mobile IP or more specifically Mobile IPv6 (MIPv6), using the version 6 of Internet Protocol (IP). MIPv6 is an Internet Engineering Task Force (IETF) standard communication protocol. It has been designed to allow mobile users to move from one network to another without experiencing discontinuity of services. Indeed, MIPv6 protocol provides continuous IP services to a mobile node (MN), the mobile node being a mobile phone, a laptop or PDA, etc., by maintaining connectivity of the MN with different networks. 
     The mobility services are deployed through a Home Agent (HA) which provides a Home Address (HoA) to a MN registered with that HA. When the MN moves away and attaches itself to a different access router, it acquires a new address, called the Care-Of Address (CoA). The MN then sends a Binding Update (BU) to the HA in order to bind the CoA to the HoA, so that traffic directed to the HoA is forwarded to the CoA. The HA replies back to the MN with a Binding Acknowledgement (BA) and forwards each packet with HoA as destination address to the CoA using a bidirectional tunnel, for example. By so doing, the mobile node (MN) is able to move without ending ongoing sessions as the HoA of the MN remains unchanged. 
     Furthermore, MIPv6 defines a Route Optimization (RO) process where the MN can send directly a Binding Update (BU) to a corresponding node (CN) in order to use a direct path. Before sending the direct BU, the MN has to perform a Return Routability (RR) test in order to give to the CN a certain level of guarantee that it can be reached at the Home Address (HoA) and the new Care-Of Address (CoA). To perform RR, the MN sends a Home Test Init (HoTI) message to the CN through the HA. The source address of the HoTI is the HoA. Simultaneously, the MN sends directly a CareOf Test Init (COTI) message to the CN with CoA as the source address. The CN replies to these two messages by including a Home Token in the HoT message and a CareOf token in the CoT message. If the MN receives those two messages, that means it is reachable via HoA and CoA. In this case, the probability to have a malicious MN is low. Then the MN combines both tokens, i.e. the Care Of Token and the Home Token, to get a binding management key (Kbm) used to send the BU to the CN. Upon receipt of the BU, the CN will then be able to assess that the Kbm was formed using both tokens. 
     A MN Proxy solution has been recently defined in order to add network support to MIPv6. The MN Proxy is generally located in the access router and performs the signaling on behalf of the MN. It reduces signaling and tunneling overhead over the radio interface between the MN and the network. A major advantage of the MN Proxy solution is that some extensions may be defined without any MN involvement, i.e. the network takes care of the extensions. Route optimization is one of such extensions. 
     Cryptographically generated addresses (CGAs) allow for proving that the sender of a data packet is actually the owner of the address (proof of ownership). In order to generate a CGA, a node has a pair of asymmetrical keys, including a public key and a private key, the public key being shared with other nodes, such as a destination node, for example. CGA was developed for increasing security and at the same time reducing traffic exchange between different nodes. The host ID part of the CGA is cryptographically generated using the address owner&#39;s private key and some parameters specific to the interface. To verify the address in a destination node, the sender should send to the destination node the CGA parameters, its public key and sign the data packet using its private key. Then, the destination node can obtain the proof of ownership by recalculating or validating the CGA with the received parameters and the public key. 
     A solution for RO using CGA has been defined. It uses a permanent Home token based on a CGA of the HoA. The MN needs to perform the Home reachability test once. After a handover, the MN sends an early BU (EBU) to the CN. The EBU contains the Home Token and the material for the CGA verification. 
     However, the existing solutions bring scalability problems and put pressure on the end-user devices. Therefore, there is a need for improved solutions using and generating CGAs. 
     SUMMARY 
     More specifically, in accordance with the present invention, there is provided a network node located on a communication path between a first node and a second node, the network node having unique information of the first node and having a private key and a public key, the public key being shared at least with the second node. The network node comprises: a generator for generating a Cryptographically Generated Address (CGA) for the first node using the unique information of the first node; an output module for assigning the CGA to the first node; an input module for receiving a message from the first node, the message being issued using the CGA and addressed to the second node; and a security module for signing the received message using the private key of the network node on behalf of the first node. The output module is further for sending the signed message to the second node, thereby enabling proof of ownership of the CGA by the second node. 
     According to a second aspect of the present invention, there is provided a network node located on a communication path between a first node and a second node, the network node having unique information of the first node. The network node comprises: a generator for generating a Cryptographically Generated Address (CGA) for the first node using the unique information of the first node; and an output module for assigning the CGA to the first node. 
     According to a third aspect of the present invention, there is provided a network node located on a communication path between a first node and a second node. The network node comprises: an input module for receiving a message from the first node, the message being issued using a CGA and addressed to the second node; a security module for signing the received message on behalf of the first node; and an output module for sending the signed message to the second node, thereby enabling proof of ownership of the CGA by the second node. 
     According to a fourth aspect of the present invention, there is provided a method for generating a cryptographically generated address (CGA). The method comprises the steps of: generating, in a network node located on a communication path between a first node and a second node, the network node having unique information of the first node, a cryptographically generated address (CGA) for the first node using the unique information of the first node; and assigning the CGA to the first node. 
     The foregoing and other objects, advantages and features of the present invention will become more apparent upon reading of the following non-restrictive description of illustrative embodiments thereof, given by way of example only with reference to the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In the appended drawings: 
         FIG. 1  is a schematic view of a MIP network according to a non-restrictive illustrative embodiment of the present invention; 
         FIG. 2  is a schematic view of a network node for generating a CGA for another node, according to a non-restrictive illustrative embodiment of the present invention; 
         FIG. 3  is a schematic view of a second network node according to a non-restrictive illustrative embodiment of the present invention; 
         FIG. 4  is a schematic view of a third network node according to a non-restrictive illustrative embodiment of the present invention; 
         FIG. 5  is a flow chart illustrating a method for generating a CGA according to a non-restrictive illustrative embodiment of the present invention; 
         FIG. 6  is a schematic view of a header of a HoTI message according to an embodiment of the present invention; and 
         FIG. 7  is a flow chart illustrating a method of routing optimization using the method of  FIG. 5 , in the MIP network of  FIG. 1 . 
     
    
    
     DETAILED DESCRIPTION 
     Generally stated, non-restrictive illustrative embodiments of the present invention provide for a network node, located in the communication path between a first node and a second node, which generates a CGA for another node, such as the first node. Thus, the embodiments of the present invention allow for separating the node generating the CGA from the node for which the CGA is generated. By so doing, one single node may generate a plurality of CGAs for many different nodes. In order to distinguish each generated CGA for each different node, the generation of each CGA takes into account unique information of each different node. 
     A very interesting application of the above-mentioned generation of CGAs can be found in the route optimization in MIPv6 using the MN Proxy solution. To do so, the HA, which is located on the communication path between a MN and a CN, gets involved in the routing optimization by generating a CGA as the home address for the MN or MN Proxy. Since scalability problems are observed when each MN has CGA capabilities, when the CGA of the home address of the MN is generated by the HA with its own private key, scalability problems are overcome. During the initial route optimization, for the home reachability test, the MN proxy, on behalf of the MN, sends a HoTI message to the HA. When the HA receives the HoTI message, it replaces the received HoTI message with a signed HoTI message, signed with its own private key. Then, the HA sends the signed HoTI message to the CN, along with the other CGA parameters, which CGA parameters are well-known in the art, and its public key. When the CN receives all this information, it can, as required, obtain the proof of ownership of the CGA, i.e. it is able to know that whoever signed the received message is the owner of the CGA generated for the MN. This new method for route optimization will be described in more detail hereinbelow. 
     Now turning to  FIG. 1 , a framework, including a MIP network  10 , for the embodiments of the present invention, will be first described. 
     The MIP network  10  includes, for example, a correspondent node (CN)  12 , connected to Internet  14  and a HA  16 , in which a MN  18  is initially registered. The HA  16  can be a network node, which provides for mobility services of the MN  18 , for example by assigning to the latter a home address (HoA). 
     The MIP network  10  also comprises at least one MN proxy and other components which are well-known in the art. More specifically, two MN proxies  20  and  22  are illustrated in  FIG. 1  as an example. 
     The MN  18 , which is first attached to the MN proxy  20 , can move around within the MIP network  10 , as shown by the arrow  19  so as to attach itself to the MN proxy  22 . In order to reduce signaling and tunneling overhead over the radio interface between the MN  18  and the network, the MN proxy  20  or  22 , which can generally be part of an access router (not shown), performs the signaling on behalf of the MN  18 . By using a MN proxy, signaling can be controlled and concentrated in the network. 
       FIG. 2  illustrates a schematic view of a network node  100 , such as the HA  16 , located on the communication path between a first node and a second node; the first node can be the MN  18  or the MN proxy  20  and the second node can be the CN  12 . 
     The network node  100  comprises a generator of CGA  102 , an output module  104 , a security module  106 , an input module  108 , a token generator  110  and a pair of asymmetrical keys including a private key  112  and a public key  114 . It should be noted that the pair of asymmetrical keys may reside in a repository  116  of the network node  100 , which may include other keys (private or public), for example. Of course, the network node  100  also comprises a plurality of other components (not shown), such as a processor or memory, for performing its usual tasks and procedures, which are well known in the art and thus will not be described further. 
     The generator of CGA  102  allows for generating a CGA for another node such as generating a HoA using CGA for the MN  18  or the MN proxy  20 , using the private key  112 . It is believed that CGA generation and proof of ownership using a pair of asymmetrical keys are already known in the art, thus CGA generation (using the private key) and proof of ownership of the CGA (using the public key) will not be further described. However, in order to distinguish the potentially many CGAs generated by the network node  100  from each other, the CGA calculation performed in the generator  102  takes into account a unique information of the node for which the generated CGA is. In the case of the MN  18 , the unique information can be for example the MN identifier or ID, which is unique to each specific MN. Also, by using the unique information of each MN  18  in the CGA calculation, it is possible to obtain different hash values for the host ID part of the CGA, for example, so that each such generated CGA can be distinguished from each other. It should be noted that the calculation of the CGA is well documented in RFC3972, which also indicates that the CGA generation method allows to have optional extension fields. In our case, the MN identifier or ID is used as an extension field in the CGA generation. 
     Once the CGA is generated by the generator  102 , using the unique information of the first node and the private key  112  of the network node  100 , the output module  104  allows for assigning the CGA to the first node. To do so, the output module  104  sends the CGA to the first node in a secured manner (i.e. through an IKEv2 exchange). The secured process such as the IKEv2 exchange provides a secure link between the network node  100  and the first node. In the context of routing optimization between the MN  18  and the CN  12 , the generated CGA comprises a HoA and the first node can be either the MN  18  or the MN proxy  20 . Then, still in the route optimization context, an option can be included in the IKEv2 exchange to indicate that the HoA provided to the MN  18  is a CGA. 
     The input module  108  allows for intercepting or receiving a message from the first node (e.g., the MN  18  or Proxy MN  20 ) issued using the CGA and addressed to the second node (e.g., the CN  12 ). 
     Upon receipt of the message, the security module  106  of the network node  100  allows for signing the received message, using the private key  112 , on behalf of the first node, since the network node  100  generated the CGA for the first node, for the purpose of maintaining CGA validation or providing CGA support. Or in other terms, the network node  100  signs on behalf of the first node for the purpose of enabling the receiver (second node) to obtain proof of ownership of the CGA. This can be also referred to as proxy signing by the network node  100 , i.e. signing a message received from another node and issued using the CGA generated for that node. For that purpose, it should be noted that the network node  100  should be located on the communication path between the first node and the second node. In the context of the MIP network  10  of  FIG. 1 , the network node can be the HA  12 . In that case, the first node can be the MN  18  or the MN proxy  20 . However, in other cases, the network node can be also the MN proxy  20 , then, the MN  18  will be the first node. 
     The input module  108  also allows for receiving messages from the second node. These messages may comprise a token for example. 
     Upon receipt of the token from the second node, the token generator  110  allows for generating a second token based on the received token. The two tokens are then sent to the first node (e.g., the MN  18  or MN Proxy  20 ) through the output module  104 . 
     It should be noted that the pair of keys, comprising the private key  112  and public key  114 , are well-known to people skilled in the art of CGA, thus they will not be described further. 
     Now turning to  FIG. 3 , a second embodiment of a network node  200  will be described. 
     The network node  200  comprises a generator of CGA  202 , an output module  204  and a pair of asymmetrical keys (i.e., a private key  206  and a public key  208 ). Of course, the network node  200  also comprises a plurality of other components (not shown), such as a processor or memory, for performing its usual tasks and procedures, which are well known in the art and thus will not be described further. 
     The generator of CGA  202  has some of the characteristics of the generator of CGA  102  of  FIG. 2 . It allows for generating a CGA for a first node, such as the MN  18 , using unique information of the first node and the private key  206 . 
     The output module  204  has some of the characteristics of the output module  104  of  FIG. 2 . It allows for assigning the generated CGA to the first node, in a secure way, e.g., using IKEv2 for example. Of course, other ways and technologies can be used for assigning the CGA to the first node. 
     In  FIG. 4 , a third embodiment of a network node  300  is illustrated. The network node  300  comprises an input module  302 , a security module  304 , an output module  306  and a generator of CGA  308 . 
     The input module  302  has some of the characteristics of the input module  108  of  FIG. 2 . It allows for receiving a message from the first node, the message being issued using a CGA, which has been generated beforehand by the generator of CGA  308 , using a private key (not shown). 
     Upon receipt of this message, the security module  304  signs the message on behalf of CGA generation, because the network node  300  has generated the CGA used to issue the message. Indeed, even though the message is from the first node, the network node  300  can sign it through the security module  304  and its private key  112  so that when the second node receives the signed message, it can detect that the network node  300  is indeed the owner of the CGA, generated by the generator of CGA  308  for the first node. The security module  304  has some of the characteristics of the security module  106  of  FIG. 2 . 
     The output module  306  allows for sending out the signed message to the second node. 
     Now turning to  FIG. 5 , a method  400  for generating a CGA will be described. 
     Method  400  starts with step  402  by generating a CGA for a first node in a network node, such as the network node  100  of  FIG. 2 , the network node  100  being located on the communication path between the first node and a second node. More specifically, the generator  102  of  FIG. 2  generates the CGA for the first node using unique information of the first node and the private key such as  112  of  FIG. 2 . 
     Then, in step  404 , the generated CGA is assigned to the first node through the output module  104  of  FIG. 2 , for example. More specifically, the CGA is assigned to the first node by using, e.g., IKEv2 for security purposes. Of course, other secure technologies can be also used. 
     Once the first node receives the CGA, it can issue a message using the received CGA and addressed to the second node. This message is then sent back to the network node  100 , for example. The network node  100  receives the message through its input module  108 . Upon receipt of this message, the security module  106  signs the received message on behalf of the first node for the CGA generation with the private key  112 . 
     Next, the output module  104  of the network node  100  sends the signed message to the second node, which is able, at will, to establish proof of ownership of the CGA. The second node is expected to have a copy of the public key  114  of the network node  100  of  FIG. 2 . 
     Once the proof of ownership has been established to the satisfaction of the second node (e.g., with or without actual CGA parameters recalculation), the second node sends a message to the network node  100 , the message comprising a first token. 
     Upon receipt of the first token, the token generator  110  of the network node  100  generates a second token, based on the first token. 
     The first and second tokens are then sent to the first node, through the output module  104  of the network node  100 . 
     Now, turning to  FIG. 7  and with reference to  FIG. 1 , an application of the embodiments of the present invention in a method  500  of route optimization in the MIP network  10  will be described. In this method, it is supposed that the network node  100  is the HA  16  of  FIG. 1 , the first node is the MN proxy  20  and the second node is the CN  12  and the method of route optimization allows the MN  18  to directly communicate with the CN  12 , for example. As mentioned hereinabove, the MN proxy controls at least a portion of the signaling on behalf of the MN  18 . Also, the HA  16  has a pair of asymmetrical keys, comprising a private key and a public key. The public key is shared with at least the second node, i.e. the CN  12 . Also, the HA  16  has a piece of unique information representing the MN  18 . 
     First, in step  502 , upon certain triggers, such as when the MN  18  attaches to the network  10 , the MN proxy  20 , on the behalf of the MN  18 , requests a HoA from the HA  16  to which the MN  18  is attached. 
     In step  504 , the HA  16  generates a CGA of the requested HoA using its private key and the unique information of the MN  18 , such as its identifier. This unique information is taken into account during the CGA calculation so as to obtain a different hash value for the host ID part of the CGA of the HoA. 
     In step  506 , the generated HoA is then assigned to the MN  18 , through IKEv2 exchange, as stated in RFC4877, for example. In this case, the HA  16  may also include an option in the IKEv2 exchange in order to indicate that the HoA provided is a CGA. 
     Once the MN proxy  20  obtains the generated HoA, a home reachability test can be performed for an initial RO process. 
     More specifically, in step  508 , the MN proxy  20  sends a HoTI message with the CN  12  as destination address, the HoTI message being issued using the CGA and being encapsulated in a tunnel which has the HA  16  as destination address. 
     Upon receipt of the HoTI message from the MN Proxy  20 , the HA  16  replaces the received HoTI message with a new HoTI message in step  510 . The new HoTI message comprises the HoA as the source address and the CN  12  as the destination address. The HA  16  also includes all the parameters required for the CGA generation or proof of ownership. The HA  16  signs the new HoTI message with its private key, such as the private key  112 . 
     For example,  FIG. 6  illustrates a portion of a header  600  that could be used with the new HoTI message created by the HA  16 . In the exemplary new HoTI message, it should be noted that a new C bit  602  is set to one (1) to indicate that the message was created by the HA  16  and that CGA was used. As one skilled in the art would readily recognize, other bits could be used in the header  600  or elsewhere in the message to achieve the same indicative purpose. Furthermore, for security reasons, if the HA  16  receives a HoTI message with the C bit  602  already set, it should reject this message. Of course, the header  600  comprises other fields for different options. 
     In step  512  the signed HoTI message is sent to the CN  12 . Upon receipt of the signed HoTI message, the CN  12  is able to validate or establish the ownership of the CGA, using the received parameters and the public key, in step  514 . 
     Thereafter, the CN  12  sends back a HoT message to the HA  16  in step  516 . The HoT message comprises, in addition to the fields defined in RFC3775, such as the Home lnit Cookie, a first token, such as an encrypted permanent Home keygen token, given by the CN  12 . This Home token can be generated as stated in RFC3775 and encrypted using the public key of the HA  16 , for example. 
     In step  518 , upon receiving the HoT message from the CN  12 , the HA  16  generates a second token. The second token is generated based on the first token. More specifically, the second token is generated by hashing the concatenation of the Home token and the CoA of the MN  18 . For example, the second token, also referred to as the HA_COA token, can be given by: 
     HA_COA token=SHA1(HA private key, (Home Token|COA)) 
     where SHA1 is a well-known hashing function. 
     In step  520 , the HA  16  creates a new HoT message, which includes the first and second tokens as well as the public key of the HA  16 . The new HoT message can optionally be protected using IPsec security association for example. Of course, other security protocols or mechanisms are also possible. 
     In step  522 , the HA  16  sends the new HoT message to the MN Proxy  20 . Upon receipt of the HoT message, in step  524 , the MN proxy  20  sends a BU message to the CN  12 , the BU message including the same fields as in RFC3775, the HA public key, the Home token and the HA_COA token. Furthermore, for increased security, the BU message can be protected with an authenticator, which is calculated using the Home token as the key for the hashing, for example. 
     Upon receiving the BU, in step  526 , the CN  12  validates the two received tokens by recomputing the Home token and the HA_COA token, which is formed by concatenating the Home token and the CoA of the MN  18 . When the validation is positive, the CN  12  can then switch data packets towards the CoA since the CN  12  knows that the HA_COA token has been computed by the HA  16  before being sent to the MN  18  at the CoA. Therefore, the MN  18  is reachable by the HoA and by the CoA. 
     In step  528 , the CN  12  sends a BA message to the MN proxy  20 . 
     After the RO is complete, in step  530 , the MN Proxy  20  has the option to send a message to the HA  16  to confirm that a RO session is ongoing. In this case, the HA  16  will be capable of keeping in its Binding Cache Entry (BCE, not shown), a list of CNs using RO with the MN  18  and its associated Home token and HA_CoA token. 
     It should be noted that after a handover of the MN Proxy  20  (or MN  18 ), the MN proxy  20  can reuse the same BU as defined in step  524  to refresh the binding at the CN  12 . More specifically, after the handover, the new MN proxy sends a BU to the HA  16 . The HA  16  computes a new HA_COA token with the new CoA. In the BA, the HA  16  sends the list of CNs using RO with the MN  18  and its associated Home token and HA_COA token. 
     The MN Proxy  20  then sends a BU to the CN  12 . The BU is constructed as in the step  522  of method  500 . 
     When receiving the BU, the CN  12  can then switch directly the data packets toward the new CoA and sends a BA to the MN Proxy  20 . 
     Some of the advantages of the above method include the fact that MN&#39;s involvement in the RO process is reduced. The number of messages exchanged after a handover is also kept low since the subsequent RO session can be established with only one BU/BA exchange between the CN  12  and the MN  18 . Also, the need for the Return Routability after handover is reduced if not completely eliminated. 
     Although the present invention has been described in the foregoing specification by means of a non-restrictive illustrative embodiment, this illustrative embodiment can be modified at will within the scope, spirit and nature of the subject invention.