JP4560432B2 - Mobile node authentication method - Google Patents

Description

  The present invention relates to a mobile node (MN) authentication method in FMIPv6 (Fast Handovers for Mobile IPv6).

  MIPv6 (Mobility Support in IPv6) assumes that a mobile node (MN) moves in a subnet. Here, in addition to the problem of packet loss loss due to delays such as movement registration when the network moves, it is necessary to realize an AAA (Authentication, Authorization, Accounting) mechanism when moving a subnet.

In order to realize the AAA mechanism at the time of movement of the subnet, particularly authentication, an authentication method as disclosed in Non-Patent Document 1 has been proposed. In this authentication method, the MN and the access router (AR) perform network access authentication between the MN and the access network by EAP (Protocol for Carrying Authentication for Network Access), which is called EAP (Extensible Authentication Protocol). In addition, a protocol for carrying authentication information is employed without depending on the method of the link layer. A protocol called Diameter is adopted between the AR and the AAA server.
Makiko Saka, Tomohide Ta and Fumio Teraoka, “Design, Implementation and Evaluation of AAA Mechanism for IPv6 Mobility Environment”, July 7, 2004, “Multimedia, Distributed, Cooperation and Mobile (DICOMO 2004) Symposium”

  In the method proposed in Non-Patent Document 1, in the visited domain of the MN, when the MN moves from the AR (PAR: Previous Access Router) before moving to another AR, In addition to PANA-based message exchange with the AR, between the NAR and the AAA server (AAAv) in the visited domain, and between the AAAv and the MN's home domain (AAAh) AAA server (AAAh) Messages are exchanged based on Diameter. That is, every time the MN moves to another AR, the authentication result is inquired to the AAA server for authentication between the MN and the domain. Since it takes time to inquire about the authentication result, there is a problem that it is difficult to realize high-speed handover.

  An object of the present invention is to provide a MN authentication method that realizes high-speed handover while maintaining the level of security required for authentication when the MN moves between ARs.

An object of the present invention is when a mobile node (MN) moves from a subnet of a PAR, which is a communicating access router (AR), to a subnet of a NAR, which is a new AR, according to FMIPv6 (Fast Hands for Mobile IPv6). MN authentication method,
Under the predictive mode, in the PAR, for the PAN session (Protocol for Carrying Authentication for Network Access) established between the PAR and the MN, the attribute of the PAN session stored in the storage device of the PAR Reading the information;
Adding attribute information of the PANA session to HI (Handover Initiate);
Transmitting HI to which attribute information of the PANA session is added to the NAR;
The NAR includes a step of receiving attribute information of the PANA session added to the HI and storing the attribute information in a storage device of the NAR.

  According to the present invention, in the message exchange according to FMIPv6 executed when moving the subnet of the MN, the attribute information of the PANA session between the already established PAR and the MN is transmitted from the PAR to the NAR. . As a result, a PANA session between the NAR and the MN is also established, so that authentication to the AAA server can be omitted. Therefore, it is possible to speed up the handover.

In a preferred aspect, in the NAR, adding a message indicating that the attribute information of the PANA session has been received to HAck (Handover Acknowledge) responding to HI;
Transmitting HAck to which the message indicating reception is added to the PAR.

In a more preferred aspect, the PAR further receives an FBU (Fast Binding Update) to which the MN adds a message requesting transfer of the PANA session attribute information to the NAR in the PAR.
When the HAck to which the message indicating the reception is added is received, an FBack (Fast Binding Acknowledgment) responding to the FBU is transmitted to the MN with an FBack to which a message indicating a response to the transfer request is added. Prepare.

  In a preferred embodiment, the NAR includes a step of receiving an FNA (Fast Neighbor Advertisement) to which the MN adds a PDI (PANA-PAA-Discover) that is a PANA message.

In addition, the object of the present invention is to move a mobile node (MN) from a subnet of a PAR that is a communicating access router (AR) to a subnet of a NAR that is a new AR in accordance with FM IPv6 (Fast Hands for Mobile IPv6). MN's authentication method when
Under the reactive mode, the NAR receives an FNA in which the MN encapsulates an FBU and adds a PDI (PANA-PAA-Discover) that is a PANA message;
Adding a message requesting transfer of the PANA session attribute information to the NAR to the PAR to an FBU (Fast Binding update) encapsulated in the FNA to which the PDI is added;
Transmitting the FBU to which the transfer request message is added to the PAR;
In the PAR, receiving the FBU to which the transfer request message is added, and reading the attribute information stored in the storage device of the PAR for the PANA session established between the PAR and the MN; ,
Adding attribute information of the PANA session to the FBack responding to the FBU;
Transmitting an FBack to which the attribute information of the PANA session is added to the NAR;
The NAR includes the step of receiving attribute information of the PANA session added to the FBack and storing the attribute information in the storage device of the NAR.

In a preferred aspect, when the NAR receives the FBack to which the attribute information of the PANA session is added, the PBR (PANA-Bind- Request), and
Transmitting the FBack with the PBR added thereto to the MN.

  In a preferred aspect, the attribute information of the added PANA session includes “Nonce”. By including “Nonce” in the attribute information of the PANA session, “PANA-Start-Request” and “PANA-Start-Answer” which are PANA messages can be omitted, and the procedure can be simplified.

  In another preferred aspect, the attribute information of the added PANA session includes “PANA MAC KEY”. By including “PANA MAC KEY” in the attribute information of the PANA session, calculation of a new “PANA MAC KEY” can be omitted.

  Further, in a preferred aspect, the attribute information of the added PANA session includes “Session lifetime”. By including “Session lifetime” in the attribute information of the PANA session, the duration of the PANA session established between the MN and the PAR can be taken over between the MN and the NAR after moving, and after the “Session lifetime” elapses. By disconnecting the session, it is possible to avoid a situation in which the session continues for a long time and to ensure security.

  In another preferred embodiment, the attribute information of the PANA session added to the FMIPv6 message or the message related to the PANA may conform to CTP (Context Transfer Protocol).

  In still another preferred embodiment, the FMIPv6 “Mobility header” is added to the FMIPv6 message in the MN, the PAR, and the NAR when the PANA session attribute information or the PANA-related message is added. Alternatively, the method includes a step of setting a flag in the reserved field of “ICMP header”. As a result, each of the MN, PAR, and NAR that has received the message in accordance with FMIPv6 can recognize that the received message includes information related to PANA.

  According to the present invention, it is possible to provide a MN authentication method that realizes high-speed handover while maintaining the security level necessary for authentication when moving between MN ARs.

  Embodiments of the present invention will be described below with reference to the accompanying drawings. FIG. 1 is a block diagram showing an outline of a system to which an authentication method according to the first embodiment of the present invention is applied. In this system, packets are transmitted and received between the MN 12 and the AR 14 (hereinafter also referred to as “PAR”). In this system, messages according to FMIPv6 are transmitted and received between MN, AR, and the like. In addition, a PANA session is established between the MN 12 and the AR 14.

  In PANA, PAA (PANA Authentication Agent), PaC (PANA Client), and EP (Enforcement Point) are defined as functional elements. In the present embodiment, it is assumed that PAA and EP are arranged on AR and PaC is arranged on MN. Hereinafter, more specifically, operations and states based on PaC, PAA, and EP are also indicated by nodes (AR14, AR16, and MN12) where each function is arranged.

In the system described above, it is assumed that the MN 12 moves and newly transmits / receives a packet using a communication path with the AR 16 (hereinafter also referred to as “NAR”). In this embodiment, the state in which the MN and the access network perform mutual authentication and the MN is authorized to use the access network is the state in which the PANA session of AR (PAA) and MN (PaC) is established. ,
By transferring the attribute information of the PANA session from the PAR 14 to the NAR 16, at the time of movement, authentication to an AAA server (not shown) is omitted, and high-speed handover is realized by realizing high-speed authentication.

  Hereinafter, in the first embodiment, the messages exchanged between the MN 12, the PAR 14, and the NAR 16 in the case of the predictive mode and the non-predictive mode (reactive mode) will be described with reference to FIG. This will be described in detail with reference to FIG. FIG. 2 is a diagram showing a message sequence when the MN moves from the PAR subnet to the NAR subnet in the predictive mode. As can be understood from FIGS. 2 and 3, the message exchange according to the present embodiment basically conforms to FMIPv6.

  When the MN 12 detects a new AR (NAR 16 in this example) using the link layer information, the MN 12 transmits an RtSolPr (Router Solicitation for Proxy) to the PAR 14 and requests information about the NAR 16 (step 201). In response to the request, the PAR 14 transmits PrRtAdv (Proxy Router Advertisement) to the MN 12, and transmits the information of the NAR 16, which is a new AR, to the MN 12 (step 202). In this step 202, a part of attribute information of the following PANA session is notified to the MN 12.

"PAA (PANA Authentication Agent: IP address of PAA) of AR in this embodiment, especially NAR16 in step 202)"
“EP (Enforcement Point: In this embodiment, a list of device identifiers of EPs) of device ID (device identifier) of AR, in particular, in step 202, NAR 16”
In the present embodiment, information can be acquired from PrRtAdv by using a MAC address as a device identifier.

  Next, the MN 12 transmits FBU (Fast Binding Update) (step 203). In the present embodiment, the FBU includes a “CT (Context Transfer) request”, that is, a request indicating that the context (in this case, PANA attribute information) is to be moved. In this specification, “CT (Context Transfer)” means that between the ARs (that is, in order to omit a message exchange necessary for establishing a state between the NAR 16 and the MN 12 after the MN 12 moves) , PAR14 and NAR16) means that the state information (Context) is moved. Information moved by CT is also referred to as CTD (Context Transfer Data). FIG. 4A is a diagram illustrating an example of a packet configuration of the message (FBU including CT request) transmitted in step 203. In the following description, the PANA message included in the FMIPv6 message is referred to as “FPANA” or displayed in the drawing. In this embodiment, the transmission source MN or AR sets a 1-bit flag in the reserved field (reserved field) of “Mobility header” or “ICMP header”, so that the reception destination MN 12 or AR becomes FPANA messages can be recognized. For example, in the example of FIG. 4A, a 1-bit flag is set in the reserved field of “Mobility header (see reference numeral 401)”. By setting the flag, the MN 12 can notify the PAR 14 that a CT is requested.

  The PAR 14 that has received the FBU transmits to the NAR 16 an HI (Handover Initiate) inquiring whether or not a new care-of address can be used (step 204). The PAR 14 includes, in the HI, the attribute information of the PANA session related to the MN 12 stored in its own storage device as CTD (Context Transfer Data). Details of the CTD will be described later. FIG. 4B is a diagram illustrating an example of a packet configuration of the message (HI (inclusion CTD)) transmitted in step 204. Also in the example of FIG. 4B, a 1-bit flag is set in the reserved field of “ICMP header (see reference numeral 402)”. Thereby, it is possible to notify the NAR 16 that the information (CTD) moved by CT is stored in the field (see reference numeral 403) after the FPANA header (FPANA header). Further, the PAR 14 stores the attribute information of the PAN session of the MN 12 stored in its own storage device in the field 403.

  FIG. 5 is a diagram illustrating a configuration example of a FPANA header (FPANA Header). As shown in FIG. 5, the FPANA header includes version information (Version: 8 bits, for example), type (Type: 8 bits), header length (Header length: 16 bits), and sequence number (Sequence Number: 32 bits). And data values.

  In addition, by transmitting HI from the PAR 14 to the NAR 16, the following PANA session attribute information can also be notified to the NAR 16.

"PaC (PANA Client: MN12 in this embodiment) device ID (Device-ID of PaC)"
"PaC IP address (IP address of PaC)"
The NAR 16 stores the received CTD in its own storage device, and transmits a HAck (Handover Acknowledge) to the PAR 14 in response to the HI (Step 205). The NAR 16 includes “CT Ack (Context Transfer Acknowledge)” in the message HAck. FIG. 4C is a diagram illustrating an example of a packet configuration of the message (HAck (inclusion CT Ack)) transmitted in step 205. Also in this example, the 1-bit flag is set in the reserved field of “ICMP header (see reference numeral 404)”, so that the NAR 16 can notify the PAR 14 that CT has been executed.

  When PAR 14 receives HAck, PAR 14 transmits FBack (Fast Binding Acknowledgment) to MN 12 (step 206). The PAR 14 includes “CT Ack” in this message. FIG. 4D is a diagram illustrating an example of a packet configuration of the message “FBack inclusion CT Ack” transmitted in Step 206. Also in this example, by setting a 1-bit flag in the reserved field of “Mobility header (reference numeral 405)”, the PAR 14 can notify the MN 12 that CT has been executed.

  Upon receiving the FBack, the MN 12 connects to the NAR 16 and transmits an FNA (Fast Neighbor Advertisement) including a PANA message PDI (PANA-PAA-Discover) (step 207). PDI is one of the messages included in “Discovery and handshake phase” in PANA. FIG. 4E is a diagram illustrating an example of a packet configuration of the message (PDI in FNA) transmitted in step 207. As described in other packet configurations, in this example as well, the execution of FPANA is notified from the MN 12 to the NAR 16 by setting a 1-bit flag in the reserved field of “Mobility header (see reference numeral 406)”. . Also, the PANA message PDI is stored in a field after the FPANA header (see reference numeral 407).

  In response to receiving the “PDI in FNA” message, the NAR 16 transmits a PBR (PANA-Bind-Request) to the MN 12 (step 208). Note that when the NAR 16 needs to return a NAack (Neighbor Advertisement Acknowledgment) to the MN 12, the NAR 16 includes the message “PBR” in the NAack. The PBR and PBA described later are messages included in the “Authentication and Authorization phase” of the PANA.

  FIG. 4F is a diagram illustrating an example of the packet configuration of the message (PBR) transmitted in step 208. In this example, “PBR” is included in NAack. Again, the execution of FPANA is notified from the NAR 16 to the MN 12 by setting a 1-bit flag in the reserved field of “ICMP header (see reference numeral 408)”. The PANA message PBR is stored in a field after the FPANA header (see reference numeral 409).

  Thereafter, the MN 12 transmits a PBA (PANA-Bind-Answer) to the NAR 16 (step 209). As a result, a PANA session is established between the MN 12 and the NAR 16.

  Next, message exchange in the non-predictive mode (hereinafter referred to as “reactive mode”) will be described. FIG. 3 is a diagram showing a message sequence when the MN moves from the PAR subnet to the NAR subnet in the reactive mode.

  If the MN 12 accesses the NAR 16 before receiving the FMIPv6 message FBack, the MN 12 transmits an FNA encapsulating the FBU to the NAR 16 (step 301). In the present embodiment, PNA (PANA-PAA-Discover), which is a PANA message, is included in this FNA. FIG. 6A is a diagram illustrating an example of a packet configuration of the message (PDI in FNA (inclusion FBU)) transmitted in step 301. Also in this example, the transmission source can recognize the FPANA message at the receiving destination by setting a 1-bit flag in the reserved field of “Mobility header” or “ICMP header”. The same applies to the messages shown in FIG. 6B and thereafter, and the description thereof is omitted. In the example shown in FIG. 6A, the PANA PDI is stored in the FPANA header and the AVPs field (see reference numeral 602).

  The NAR 16 that has received the message transmits an FBU to the PAR 14 (step 302). In the present embodiment, the NAR 16 includes “CT request” in the FBU. This “CT request” is a CTD transmission request of the MN 12. FIG. 6B is a diagram illustrating an example of a packet configuration of the message (FBU including CT request) transmitted in step 302.

  Upon receipt of the message, the PAR 14 transmits an FBack to the NAR 16 in response to the message (step 303). In this embodiment, the PAR 14 includes the CTD related to the PAN session of the MN 12 stored in its own storage device in this message FBack. FIG. 6C is a diagram illustrating an example of a packet configuration of the message (FBack (inclusion CTD)) transmitted in step 303. In this example, the CTD related to the MN 12 is stored in the field after the FPANA header (see reference numeral 603).

  When receiving the message, the NAR 16 stores the CTD related to the MN 12 in its own storage device. Also, an FBack including the PANA message PBR is transmitted to the MN 12 (step 304). Note that when the NAR 16 needs to return NAck to the MN 12, the NAR 16 includes “FBack including the message PBR” in the NAck. FIG. 6D is a diagram illustrating an example of a packet configuration of the message (PBR in FBack) transmitted in step 304. In this example, a message is included in NAck. In FIG. 6D, the PANA message PBR is stored in the field after the FPANA header (see reference numeral 604).

  Thereafter, the MN 12 transmits a PBA (PANA-Bind-Answer) to the NAR 16 (step 305). As a result, a PANA session is established between the MN 12 and the NAR 16.

  According to the present embodiment, the PANA session attribute information is transferred from the PAR 14 to the NAR 16 according to the FMIPv6 message sequence, so that the PANA session is established between the MN 12 and the NAR 16 without authentication to the AAA server. It becomes possible.

  Hereinafter, in this embodiment, attribute information of the PANA session regarding the MN 12 moving from the PAR 14 to the NAR 16 will be described.

  Of the attribute information of the PANA session stored in the storage device of the PAR 14, it is read from the storage device in the PAR 14, transmitted to the NAR 16 as the CTD added to the message in steps 204 and 303, and stored in the storage device in the NAR 16 The attribute information of the PANA session to be performed includes the following. The attribute information of the PANA session is information that both the MN and AR have (that is, stored in the respective storage devices) necessary for establishing the PANA session between the MN and AR. Say.

"Retransmission interval"
"Session lifetime"
"PANA MAC KEY"
"Nonce"
“Nonce” includes both those generated in PaC (MN) and those generated in PAA (AR). In addition, by moving “Nonce” from PAR14 to NAR16 in CT, the message exchange “PANA-Start-Request” and “PANA-Start-Answer” according to PANA is omitted between MN12 and NAR16. can do. Of course, “Nonce” may not be included in the CTD transmitted from the PAR 14 to the NAR 16, and these may be generated again by exchanging messages between the MN 12 and the NAR 16.

  The PAR 14 may include the following information as a CTD.

"ISP information"
"AAA server information"
"Total communication packets"
"Total connection time"
These pieces of information, for example, “ISP information” and “AAA server information” are necessary for grasping which AAA of which ISP the AR should inquire when the lifetime of the session expires. The “total communication packet” and “total connection time” are for billing when actually operating.

  When “PANA MAC KEY” is not included in CTD, the following information is moved from PAR 14 to NAR 16, and NAR 16 newly generates “PANA MAC KEY” based on the moved information. However, this may be stored in its own storage device.

"Retransmission interval"
"Session lifetime"
"AAA-Key-Int"
"AAA-Key-Identifier"
"Nonce"
In this case, in NAR, a new AAA-Key is calculated using AAA-Key-Int, and a new PANA MAC KEY is calculated using AAA-Key.

  Alternatively, the NAR 16 may generate a new “PANA MAC KEY” by moving the following information from the PAR 14 to the NAR 16.

"Retransmission interval"
"Session lifetime"
"AAA-Key"
"AAA-Key-Identifier"
"Nonce"
In this case, a new PANA MAC KEY is calculated at the NAR using AAA-Key.

  Next, attribute information of other PANA sessions will be described.

  For example, “Session ID” is information generated every time a session is started between the MN and the AR, and is notified from the MN 12 to the NAR 16 by PDI (PANA-PAA-Discover). Specifically, in the predictive mode, notification is performed by PDI in FNA in step 208 of FIG. 2, and in the reactive mode, notification is performed by PDI in FNA (inclusion FBU) in step 301 of FIG. As another method, sharing may be performed by PBR (PANA-Bind-Request) and PBA (PANA-Bind-Answer).

  The following information is notified from the PAR 14 to the NAR 16 in the FMIPv6 message transmission / reception. These have already been described in connection with step 204.

“Device-ID of PaC” (notified by HI)
“IP address of PaC” (notified by HI)
Further, the following information is notified from the PAR 14 to the MN 12 in FMIPv6 message transmission / reception. These have already been described in connection with step 202.

“IP address of PAA” (notified by PrRtAdv)
“List of devices identifiers of EPs” (notified by PrRtAdv)
The following attribute information is initialized by the exchange of PBR (PANA-Bind-Request) / PBA (PANA-Bind-Answer).

"Sequence number of the last transmitted request"
"Sequence number of the last received request"
"Last transmitted message payload"
Furthermore, the following attribute information is shared by PBR and PBA (PANA-Bind-Answer).

"Protection-Capability"
Next, a second embodiment of the present invention will be described. Also in the second embodiment, the outline of the system is the same as that shown in FIG. In the second embodiment, in order to realize CT (Context Transfer Protocol), CTP (Context Transfer Protocol: J. Laughney et al., “Context Transfer Protocol”, “draft-Protocol”. ietf-seamobi-ctp-11.txt ", February 2005).

  Hereinafter, in the second embodiment, the messages exchanged between the MN 12, the PAR 14, and the NAR 16 in the case of the predictive mode and the non-predictive mode (reactive mode) will be described with reference to FIG. This will be described in detail with reference to FIG. FIG. 7 is a diagram illustrating a message sequence when the MN moves from the PAR subnet to the NAR subnet in the predictive mode according to the second embodiment. As can be understood from FIGS. 7 and 8, the message exchange according to the second embodiment basically conforms to FMIPv6 as in the first embodiment. As can be understood from FIGS. 2 and 7, the messages transmitted and received between the MN 12, the PAR 14, and the NAR 16 are substantially the same. Therefore, only the parts different from the message according to the first embodiment will be described. In the first embodiment, the attribute information of the PANA session moved from the PAR 14 to the NAR 16 is described as “CTD”. However, in the second embodiment, the message “CTD ( In order to avoid confusion with “Context Transfer Data” ”, lower case“ ctd ”is described.

  Steps 701 and 702 are the same as steps 201 and 202 in FIG. 2, respectively. After this message exchange, the MN 12 transmits an FBU including a message CTAR (Context Transfer Activate Request) according to the CTP to the PAR 14 (step 703).

  FIG. 9A is a diagram illustrating an example of a packet configuration of the message (CTAR in FBU) transmitted in step 203. As in the first embodiment, the transmission source MN or AR sets a 1-bit flag in the reserved field of “Mobility header (for example, reference numeral 901)” or “ICMP header”. The receiving MN or AR recognizes the FPANA message. In FIG. 9A, when the flag is set, the PAR 14 can recognize “CTAR data (see reference numeral 902)” added to the end.

  The PAR 14 transmits an HI including a CTD (Context Transfer Data) in accordance with CTP to the NAR 16 (step 704). As shown in FIG. 9B, “CTD data” is added to the end of the message transmitted in step 704 as well. In this step, the attribute information of the PANA session related to the MN 12 can be moved from the PAR 14 to the NAR 16 as “ctd”. The NAR 16 that has received the attribute information of the PANA session stores it in its own storage device.

  In response to the HI, the NAR 16 transmits HAck including a CTDR (Context Transfer Data Reply) to the PAR 14 (step 705). As shown in FIG. 9C, “CTDR Data” is added to the end of the message (see reference numeral 904). With the flag set in the reserved field of “ICMP header” and “CTDR Data”, the NAR 16 can notify the PAR 14 that CT has been executed.

  When the PAR 14 receives the HAck, the PAR 14 transmits an FBack including a CTAA (Context Transfer Activate Ack) to the MN 12 (Step 706). As shown in FIG. 9D, “CTAA Data” is added to the end of this message (see reference numeral 905). With the flag set in the reserved field of “Mobility header” and “CTAA data”, the PAR 16 can notify the MN 12 that CT (Context Transfer) has been executed.

  Upon receiving the FBack, the MN 12 connects to the NAR 16 and transmits an FNA including the PANA message PDI and CTAR (step 707). As shown in FIG. 9 (e), “FPANA header” and “AVPs” (refer to reference numeral 906) storing message PDI and “CTAR data (refer to reference numeral 907)” are added to the message.

  In response to the message reception, the NAR 16 transmits a PBR to the MN 12 (Step 708). When the NAR 16 needs to return NAack to the MN 12, the NAR 16 includes the message PBR in the NAck. The message transmitted in step 708 shown in FIG. 9 (f) is the same as that shown in FIG. 4 (f). Step 709 executed subsequently is the same as step 209 in FIG. As a result, a PANA session is established between the MN 12 and the NAR 16.

  Next, message exchange in the reactive mode in the second embodiment will be described. FIG. 8 is a diagram illustrating a message sequence when the MN moves from the PAR subnet to the NAR subnet in the reactive mode according to the second embodiment.

  The MN 12 transmits the FNA encapsulating the FBU to the NAR 16 (Step 801). In the present embodiment, the FNA includes a CTAR according to PDI and CTP, which are PANA messages. FIG. 10A is a diagram illustrating an example of a packet configuration of the message (PDI in FNA (inclusion FBU, CTAR)) transmitted in step 801. PDI is stored in the area indicated by reference numeral 1001, and “CTAR data” is stored in the area indicated by reference numeral 1002.

  The NAR 16 that has received the message transmits an FBU including a CT-req (Context Transfer Request) to the PAR 14 (step 802). In the present embodiment, the NAR 16 includes “CT-req” in the FBU. As shown in FIG. 10B, “CT-req data” is added to the end of the message (see reference numeral 1003).

  Upon receipt of the message, the PAR 14 transmits an FBack including the CTD to the NAR 16 in response to the message (step 803). In the present embodiment, the PAR 14 includes the attribute information of the PANA session related to the MN 12 stored in its storage device in the message FBack as “CTD data” according to the CTP. As shown in FIG. 10C, “CTD data” is added to the end of the message (see reference numeral 1004). In this step, the attribute information of the PANA session related to the MN 12 can be moved from the PAR 14 to the NAR 16 as “ctd”.

  Upon receiving the message, the NAR 16 stores the PANA session attribute information regarding the MN 12 in its own storage device. Also, an FBack including a PANA message PBR and a CTAA (Context Transfer Activate Ack) according to CTP is transmitted to the MN 12 (step 804). Note that when the NAR 16 needs to return the NAack to the MN 12, the NAR 16 includes the message PBR in the NAack. As shown in FIG. 10D, PBR is stored in the area indicated by reference numeral 1005, and “CTAA data” is stored in the area indicated by reference numeral 1006.

  Thereafter, the MN 12 transmits a PBA to the NAR 16 (Step 805). As a result, a PANA session is established between the MN 12 and the NAR 16.

  Also in the second embodiment, a PANA session is established between the MN 12 and the NAR 16 without authentication to the AAA server by transferring the PANA session attribute information from the PAR 14 to the NAR 16 according to the FMIPv6 message sequence. It becomes possible to make it.

  In the first embodiment and the second embodiment, it has been described that “Session lifetime” can be included in the attribute information of the PANA session notified from the PAR to the NAR. By notifying the NAR of the “Session lifetime”, the duration of the PANA session established between the MN and the PAR can be taken over between the MN and the NAR, and the session is disconnected after the “Session lifetime” time elapses. As a result, it is possible to avoid a situation in which a long session is continued and to ensure security. Note that when the “Session lifetime” has elapsed, a new PANA session is established between the MN and the NAR. In this case, as described in Non-Patent Document 1, the NAR may exchange a message for authenticating the MN with the AAA server according to “Diameter”.

  Also, it is desirable to terminate the PANA session between the old PAA (that is, PAR) and the MN in accordance with the FMIPv6 tunnel lifetime. In the NAR, the original care-of address is available during the period indicated by the FMIPv6 tunnel lifetime. Therefore, after the PAR notifies the NAR of the attribute information of the PANA session related to the MN (see, for example, steps 204 and 303), the PAR sets the “session lifetime” of the PANA session attribute information to the tunnel lifetime. rewrite. Thereby, waste of resources can be saved by releasing unused sessions.

  The present invention is not limited to the above embodiments, and various modifications can be made within the scope of the invention described in the claims, and these are also included in the scope of the present invention. Needless to say.

FIG. 1 is a block diagram showing an outline of a system to which an authentication method according to the first embodiment of the present invention is applied. FIG. 2 is a diagram illustrating a message sequence when the MN moves from the PAR subnet to the NAR subnet in the predictive mode according to the first embodiment. FIG. 3 is a diagram illustrating a message sequence when the MN moves from the PAR subnet to the NAR subnet in the reactive mode according to the first embodiment. FIG. 4 is a diagram illustrating a packet configuration example of a message transmitted between the MN and the AR in the predictive mode according to the first embodiment. FIG. 5 is a diagram illustrating a configuration example of an FPANA header (FPANA Header). FIG. 6 is a diagram illustrating a packet configuration example of a message transmitted between the MN and the AR in the reactive mode according to the first embodiment. FIG. 7 is a diagram illustrating a message sequence when the MN moves from the PAR subnet to the NAR subnet in the predictive mode according to the second embodiment. FIG. 8 is a diagram illustrating a message sequence when the MN moves from the PAR subnet to the NAR subnet in the reactive mode according to the second embodiment. FIG. 9 is a diagram illustrating a packet configuration example of a message transmitted between the MN and the AR in the predictive mode according to the second embodiment. FIG. 10 is a diagram illustrating a packet configuration example of a message transmitted between the MN and the AR in the reactive mode according to the second embodiment.

Explanation of symbols

12 MN
14 AR (PAR)
16 AR (NAR)

Claims (7)

MN authentication method when a mobile node (MN) moves from a subnet of a PAR that is a communicating access router (AR) to a subnet of a NAR that is a new AR according to FMIPv6 (Fast Handovers for Mobile IPv6) Because
Under predictive mode, in the PAR, the MN adds a message requesting the transfer of the PANA session attribute information to the NAR, and the first field in the reserved field of the “Mobility Header” is used to recognize the transfer request. Receiving an FBU (Fast Binding Update) in which the flag is set;
When the first flag is set and an FBU to which a message is added is received, the PANA (Protocol for Carrying Authentication for Network Access) session established between the PAR and the MN Reading the attribute information of the PANA session stored in the storage device of the PAR;
Data including attribute information of the PANA session is added to a PANA header and fields after the PANA header in HI (Handover Initiate), and a second flag is set in the reserved field of “ICMP header” to recognize the PANA message. A step of setting
Transmitting the HI to which the attribute information of the PANA session is added and the second flag is set to the NAR;
In the NAR, receiving the attribute information of the PANA session added to the HI and storing it in the storage device of the NAR;
In the NAR, a message indicating that the PANA session attribute information has been received is added to the HAck (Handover Acknowledge) responding to the HI, and the reserved field of the “ICMP header” is used to recognize the PANA message. Setting a flag of 3;
Sending HAck to which the message indicating the reception is added and the third flag is set, to the PAR;
When the HAck to which the third flag is added and the message indicating the reception is received, the FBack (Fast Binding Acknowledgment) that responds to the FBU includes a message indicating the response to the transfer request. Sending to the MN;
In the NAR, the MN adds data including PDI (PANA-PAA-Discover), which is a PANA message, to the PANA header and the fields after the PANA header, and also recognizes the PANA message so that the "Mobility header" Receiving an FNA (Fast Neighbor Advertisement) in which a fourth flag is set in the reserved field. MN authentication method when a mobile node (MN) moves from a subnet of a PAR that is a communicating access router (AR) to a subnet of a NAR that is a new AR according to FMIPv6 (Fast Handovers for Mobile IPv6) Because
Under the reactive mode, in the NAR, the MN encapsulates the FBU, adds data including PANA (PANA-PAA-Discover), which is a PANA message, to the PANA header and the fields after the PANA header, Receiving FNA (Fast Neighbor Advertisement) in which a fifth flag is set in the reserved field of “Mobility header” in order to recognize the PANA message;
To add a message requesting transfer of PANA session attribute information to the NAR to the FPAR (Fast Binding Update) encapsulated in the FNA to which the PDI is added, and to recognize the message Setting a sixth flag in the reserved field of “Mobility header”;
Sending the FBU to which the transfer request message is added and the sixth flag is set to the PAR;
In the PAR, the transfer request message is added, the FBU in which the sixth flag is set is received, and the PAN session established between the PAR and the MN is stored in the storage device of the PAR. Reading the stored attribute information;
In the FBack responding to the FBU, data including attribute information of the PANA session is added to the PANA header and the fields after the PANA header, and a flag is set in the reserved field of the “Mobility header” to recognize the PANA message. 6 setting steps;
Sending FBack to which the attribute information of the PANA session is added and the sixth flag is set to the NAR;
Receiving the attribute information of the PANA session added to the FBack and having the sixth flag set in the NAR, and storing the attribute information in a storage device of the NAR. Method. Further, when the NAR receives the FBack in which the sixth flag is set and the attribute information of the PANA session is added, an FBack responding to the FBU encapsulated in the FNA includes a PANA header and a PANA header and the subsequent ones. Adding data including PBR (PANA-Bind-Request), which is a PANA message, to the field of, and setting a seventh flag in the reserved field of “ICMP header” to recognize the PANA message;
The method according to claim 2, further comprising: transmitting the FBack to which the PBR is added and the seventh flag is set to the MN.   The method according to any one of claims 1 to 3, wherein the attribute information of the added PANA session includes "Nonce".   4. The method according to claim 1, wherein the attribute information of the added PANA session includes “PANA MAC KEY”. 5.   4. The method according to claim 1, wherein the attribute information of the added PANA session includes “Session lifetime”. 5.   The attribute information of the PANA session added to the FMIPv6 message or the message related to the PANA conforms to CTP (Context Transfer Protocol), and is described in any one of claims 1 to 6. Method.

Images