JP4778565B2 - 通信方法、通信システム、モバイルノード及び通信ノード - Google Patents

通信方法、通信システム、モバイルノード及び通信ノード Download PDF

Info

Publication number
JP4778565B2
JP4778565B2 JP2008542172A JP2008542172A JP4778565B2 JP 4778565 B2 JP4778565 B2 JP 4778565B2 JP 2008542172 A JP2008542172 A JP 2008542172A JP 2008542172 A JP2008542172 A JP 2008542172A JP 4778565 B2 JP4778565 B2 JP 4778565B2
Authority
JP
Japan
Prior art keywords
care
addresses
bulk
mobile node
interfaces
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.)
Expired - Fee Related
Application number
JP2008542172A
Other languages
English (en)
Other versions
JPWO2008053955A1 (ja
Inventor
隆 荒牧
啓吾 阿相
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.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
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 Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2008542172A priority Critical patent/JP4778565B2/ja
Publication of JPWO2008053955A1 publication Critical patent/JPWO2008053955A1/ja
Application granted granted Critical
Publication of JP4778565B2 publication Critical patent/JP4778565B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/082—Mobility data transfer for traffic bypassing of mobility servers, e.g. location registers, home PLMNs or home agents
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/14—Mobility data transfer between corresponding nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

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)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、複数のインタフェースを有し、複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法、通信システム、モバイルノード及び通信ノードに関する。
標準のＭＩＰｖ６（非特許文献１）には、ルート最適化時におけるＣＮがＭＮを認証する手段としてＲＲ（Return Routability）手続が開示されている。ＭＩＰｖ６のＲＲは、ＨｏＡテストによる不正なリダイレクションからの保護と、ＣｏＡテストによるリーチャビリティの確認からなる。
一方、Ｍｏｎａｍｉ６（Mobile Nodes and Multiple Interfaces in IPv6）では、モバイルノード（ＭＮ）が複数のインタフェースを有する場合のために種々の提案が成されている。また、モバイルＩＰ（Internet Protocol）を利用するＭＮは、移動先のアドレスである気付けアドレス（ＣｏＡ）を、自身のホームアドレス（ＨｏＡ）を管理するホームエージェント（ＨＡ）に登録し、ＨｏＡあてパケットの転送を依頼する。ＭＮが、複数のＣｏＡを１つのＨｏＡに対して同時に関連付けて登録することができれば、複数のインタフェースを備えるＭＮは、それぞれのインタフェースに割り当てられたＣｏＡを登録することで、インタフェースの状態に応じて使用するＣｏＡを瞬時に切り替えることが可能となる。図６は従来のＭｏｎａｍｉ６におけるバルクＢＵ（バインディング・アップデート）を示す説明図である。非特許文献２には、図６に示すようにＭＮ１が複数のＣｏＡを１つのＨｏＡに関連付けてＨＡ２に登録（Bulk mCoA BU）する手法が記述されている。ルート最適化（ＲＯ：Route Optimazation）を行う手段については、Ｍｏｎａｍｉ６には、何らの記載はない。
D.Johnson, C.Perkins and J.Arkko, "Mobility Support in IPv6", RFC3775, June 2004 R.Wakikawa, T.Ernst, K.Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00.txt, June 2006.
ところで、ＭＮが複数のＣｏＡをＨＡにバルクＢＵ（バインディング・アップデート）登録するＭｏｎａｍｉ６を、ＣＮがＭＮを認証するＭＩＰｖ６のＲＲ手順に単純に組み合わせ、この組み合わせたＲＲ手順において、ＭＮがＣＮに対して、複数のＣｏＡに関連するバインディング・メッセージを一括して行うこと（バルクＢＵ）が考えられる。しかしながら、図６に示すようなＭｏｎａｍｉ６のBulk mCoA BUでは、ＭＮ１−ＨＡ２間のセキュリティはＩＰｓｅｃにより保護されているという観点から、さらにバルクＢＵに対する認証を行うという概念がない。これに対し、ＣＮ３がＭＮ１を認証することを目的とするＭＩＰｖ６のＲＲ手順では、ＭＮ１−ＣＮ３間がＩＰｓｅｃでセキュアに保護されている前提を置くことができないため、ＢＵメッセージの内容が異なり、ＲＲ手順におけるＢＵメッセージでは、個々のＣｏＡ毎にバインディング管理キー（Ｋｂｍ）や署名（ＭＡＣ）が必要である（後述）。このため、Ｍｏｎａｍｉ６のＨＡあてのバルクＢＵをＭＮ１−ＣＮ３間のＲＲ手順に適用することができず、ＭＮ１−ＣＮ３間のＲＲ手順におけるＢＵメッセージは個々のＣｏＡ毎にＣＮあてに送る必要がある。
図７はこの場合の動作、すなわち本発明が解決しようとする課題を示し、この図を参照しながらＭＩＰｖ６のＲＲ手順を説明する。まず、
（１）ＭＮ１はＨｏＡ、ＣｏＡ毎のクッキーを生成して、ＣＮ３あてのＨｏＴＩ（Home-Test-Init）メッセージをＨＡ２あてにカプセル化してホームネットワーク４及び外部ネットワーク５ａ経由で送信するとともに、複数（ｎ個）のＣｏＡ[1]〜[n]の各々についての直接ＣＮ３あてのＣｏＴｉ（Care-of-Test-Init）[1]〜[n]メッセージを個別に外部ネットワーク５ａ、５ｂ経由でＨＡ２を介することなく直接ＣＮ３へ送信することにより、ＨｏＡ、および各ＣｏＡ毎のクッキーをＣＮ３に送信する。
（２）ＣＮ３はこれに応答して、各クッキーなどからＨｏＡ、ＣｏＡ[1]〜[n]毎の署名用トークンを生成して、ＨＡ２経由のＭＮ１あてのＨｏＴ（Home-Test）メッセージを送信するとともに、ＣｏＡ[1]〜[n]についての直接ＭＮ１あてのＣｏＴ（Care-of-Test）[1]〜[n]メッセージを送信することにより署名用トークンを送信する。
（３）次いで、ＭＮ１はこれに応答して、各署名用トークンなどからＣｏＡ[1]〜[n]毎のバインディング管理キーＫｂｍ[1]〜[n]を生成してそれぞれのメッセージ認証コードＭＡＣ[1]〜[n]（ＭＡＣ：Message Authentification Code）し、ＣｏＡ[1]〜[n]の各々についての直接ＣＮ３あてのバインディング・アップデート・メッセージＢＵ[1]〜[n]を個々に送信することにより、Ｋｂｍ[1]〜[n]及びＭＡＣ[1]〜[n]を送信する。ＣＮ３はＭＮ１とは別個に、かつＭＮ１と同様にＭＡＣ[1]〜[n]などを生成し、ＢＵ[1]〜[n]メッセージを認証する。
（４）オプションとして、ＣＮ３はＢＵ[1]〜[n]メッセージに応答してバインディング確認メッセージＢＡ[1]〜[n]を送信してもよい。このため、（１）〜（３）では、複数のＣｏＡの各々についてＣｏＴｉ、ＣｏＴ、ＢＵの各メッセージを送信するので、非常に多く（３ｎ個）のメッセージを送信する必要があるという問題点がある。
本発明は上記の問題点に鑑み、モバイルノード（ＭＮ）と相手先の通信ノード（ＣＮ）との間で認証を行うＲＲ（Return Routability）手続を行う場合のメッセージ数を減少させることができる通信方法、通信システム、モバイルノード及び通信ノードを提供することを目的とする。
本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法であって、
前記モバイルノードが、前記複数のインタフェースの各々からそれぞれ第１のメッセージを個々に前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で前記モバイルノードに送信するステップと、
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対して共通の認証コードを認証するステップとを有する。
また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムであって、
前記モバイルノードが、前記複数のインタフェースの各々からそれぞれ第１のメッセージを個々に前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で前記モバイルノードに送信する手段と、
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを有する。
また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記モバイルノードであって、
前記複数のインタフェースの各々からそれぞれ第１のメッセージを前記相手先の通信ノードに個々に送信する手段と、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で自身に送信した場合に、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段とを有し、
前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証するようにした。
また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、
前記モバイルノードが、前記複数のインタフェースの各々からそれぞれ第１のメッセージを自身に個々に送信した場合、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で前記モバイルノードに送信する手段と、
前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを自身に送信した場合、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを有する。
また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法であって、
前記モバイルノードが、前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで前記モバイルノードに送信するステップと、
前記モバイルノードが、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバイルノードに送信するステップと、
前記モバイルノードが、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断するステップとを有する。
また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムであって、
前記モバイルノードが、前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで前記モバイルノードに送信する手段と、
前記モバイルノードが、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバイルノードに送信する手段と、
前記モバイルノードが、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断する手段とを有する。
また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記モバイルノードであって、
前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで自身に送信した場合、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを自身に送信した場合、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを前記相手先の通信ノードに送信する手段とを有し、
前記相手先の通信ノードが、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断するようにした。
また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、
前記モバイルノードが、前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを自身に送信した場合、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで前記モバイルノードに送信する手段と、
前記モバイルノードが、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを自身に送信した場合、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバイルノードに送信する手段と、
前記モバイルノードが、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを自身に送信した場合、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断する手段とを有する。
この構成により、モバイルノード（ＭＮ）と相手先の通信ノード（ＣＮ）との間で認証を行うＲＲ（Return Routability）手続を行う場合のメッセージ数を減少させることができる。
本発明によれば、モバイルノード（ＭＮ）と相手先の通信ノード（ＣＮ）との間で認証を行うＲＲ（Return Routability）手続を行う場合のメッセージ数を減少させることができる。
以下、図面を参照して本発明の実施の形態について説明する。
＜第１の実施の形態＞
図１は本発明に係る通信システムの第１の実施の形態の構成とメッセージを示す説明図、図２は第１の実施の形態の通信シーケンスを示す。第１の実施の形態では、複数のＣｏＡの各々についてＣｏＴｉ、ＣｏＴの各メッセージを送信し、ＢＵメッセージを複数のＣｏＡに対して一括（バルクＢＵ）で送信する。なお、図１では、ＭＮ１は２つのインタフェースを有し、ＣｏＡが２つである場合を示す。このため、ＣｏＴｉメッセージとＣｏＴメッセージも２つのみ（ＣｏＴｉ１、ＣｏＴｉ２）、（ＣｏＴ１、ＣｏＴ２）を示す。
（１）ＣｏＴｉ（ＨｏＴｉ）
まず、ＭＮ１はホームアドレス用のクッキーＫ０（Home Init Cookie）と気付けアドレスＣｏＡ[1]〜[n]用の各クッキーＫ１[1]〜[n]（Care of Init Cookie）を生成する。そして、ＭＮ１はＣＮ３に対し、クッキーＫ０を含むＨｏＴｉメッセージをＨＡ２経由で送信するとともに、各クッキーＫ１[1]〜[n]を含むＣｏＴｉ[1]〜[n]メッセージを個別に、かつ直接送信する。ここで、ＭＮ１からＨＡ２あてのメッセージのパケットのアドレスについては、ＣＮあてパケットをＨＡあてパケットでカプセル化したものである。また、ＣｏＴｉ[1]〜[n]メッセージの各パケットの送信元アドレスは、それぞれＣｏＡ[1]〜[n]である。
（２）ＣｏＴ（ＨｏＴ）
ＣＮ３はあらかじめ、秘密鍵Ｋcnとノンス（nonce）テーブルを保持し、ＣｏＴｉ[1]〜[n]メッセージを受け取ると、秘密鍵Ｋcnと、ＨｏＡ、ＣｏＡ[1]〜[n]、nonce（Ｎｉ、Ｎｊ）のハッシュ値から、以下のようにホームアドレスＨｏＡ用の署名用トークンＴ０と気付けアドレスＣｏＡ[1]〜[n]用の各署名用トークンＴ１[1]〜[n]を生成する。なお、ＣｏＡ[1]〜[n]のＮｊは、共通であっても、また、別個に異なるものでもよい。
Ｔ０ ：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＨｏＡ，Ｎｉ、０））
Ｔ１[1]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[1]，Ｎｊ、１））
Ｔ１[2]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[2]，Ｎｊ、１））
・・・・・
Ｔ１[n]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[n]，Ｎｊ、１））
そして、ＣＮ３はＭＮ１に対し、以下のようにクッキーＫ０、署名用トークンＴ０、ノンステーブルインデックスｉなどを含むＨｏＴメッセージをＨＡ２経由で送信するとともに、クッキーＫ１[1]〜[n]、署名用トークンＴ１[1]〜[n]、ノンステーブルインデックスｊなどを含むＣｏＴ[1]〜[n]メッセージを直接、かつ個別に送信する。
ＨｏＴ ：（Ｋ０，Ｔ０，ｉ・・・）
ＣｏＴ[1]：（Ｋ１[1]，Ｔ１[1]，ｊ・・・）
ＣｏＴ[2]：（Ｋ１[2]，Ｔ１[2]，ｊ・・・）
・・・・・
ＣｏＴ[n]：（Ｋ１[n]，Ｔ１[n]，ｊ・・・）
＜課題＞
ここで、上記の（１）、（２）における個々のＣｏＡ毎の手順は、標準のＭＩＰｖ６のＲＲ手順（ＲＦＣ３７７５）に記載されており、公知である。また、このＢＵメッセージ送信手順では、ＣｏＡ[1]〜[n]個々のＢＵメッセージを送信するために、以下のようにトークンのハッシュ値からバインディング管理キーＫbm[1]、Ｋbm[2]〜Ｋbm[n]をそれぞれ生成する。
Ｋbm[1]：ＳＨＡ１（Ｔ０，Ｔ１[1]）
Ｋbm[2]：ＳＨＡ１（Ｔ０，Ｔ１[2]）
・・・・・
Ｋbm[n]：ＳＨＡ１（Ｔ０，Ｔ１[n]）
また、このＫbm、ＣｏＡ、ＣＮアドレス、ＢＵのハッシュ値から以下のようにして署名であるＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]を生成する。
ＭＡＣ[1]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[1]，ＣＮアドレス，ＢＵ）
ＭＡＣ[2]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[2]，ＣＮアドレス，ＢＵ）
・・・・・
ＭＡＣ[n]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[n]，ＣＮアドレス，ＢＵ）
そして、ＭＮ１は、ＣＮ３に対する個々のＢＵメッセージＢＵ[1]、ＢＵ[2]〜ＢＵ[n]として、以下の内容を含むメッセージを生成し、送信する。
ＢＵ[1]（ＨｏＡ，ＣｏＡ[1]，ｉ，ｊ，seq＃，ＭＡＣ[1]）
ＢＵ[2]（ＨｏＡ，ＣｏＡ[2]，ｉ，ｊ，seq＃，ＭＡＣ[2]）
・・・・・
ＢＵ[n]（ＨｏＡ，ＣｏＡ[n]，ｉ，ｊ，seq＃，ＭＡＣ[n]）
ＣＮ３はＭＮ１と別個に、また、ＭＮ１と同様に、Ｋbm[1]、Ｋbm[2]〜Ｋbm[n]をそれぞれ生成し、次いでこのＫbm[1]、Ｋbm[2]〜Ｋbm[n]などからＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]をそれぞれ生成してＢＵメッセージＢＵ[1]、ＢＵ[2]〜ＢＵ[n]内のＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]と比較し、一致した場合に「認証ＯＫ」とし、バインディング確認（ＢＡ）メッセージを個別にＭＮ１に返信する。このため、ＢＵメッセージの数がＣｏＡの数だけ必要になる。また、Ｍｏｎａｍｉ６では、ＢＵの認証という概念がない。
＜第１の実施の形態の解決策＞
（３）これに対し、第１の実施の形態では、ＢＵメッセージの数を減少してバルクＢＵメッセージを生成するために、ＭＮ１はまず、以下のように全てのトークンのハッシュ値からＣｏＡ[1]〜[n]に対して共通のバインディング管理キーＫbm(common)を生成し、
Ｋbm(common)：ＳＨＡ１（Ｔ０，Ｔ１[1]，Ｔ１[2]〜[n]）
次いで、このＫbm(common)と、一例として全てのＣｏＡ[1]〜[n]などから以下のようにして、ＣｏＡ[1]〜[n]に対して共通のＭＡＣ(common)を生成する。
ＭＡＣ(common)：ＨＭＡＣ＿ＳＨＡ１（Ｋbm(common)，（ＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]，ＣＮアドレス，ＢＵ））
そして、ＭＮ１は、ＣＮ３に対するバルクＢＵメッセージとして、以下の内容を含むＣｏＡ[1]〜[n]に対して共通のメッセージを生成し、送信する。
Bulk ＢＵ（ＨｏＡ，ＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]，ｉ，ｊ，seq＃，ＭＡＣ）
（４）ＣＮ３はＭＮ１と別個に、また、ＭＮ１と同様に、Ｋbm(common)を生成し、次いでこのＫbm(common)などからＭＡＣ(common)をそれぞれ生成してバルクＢＵメッセージ内のＭＡＣ(common)と比較し、一致した場合に「認証ＯＫ」とし、バインディング確認（ＢＡ）メッセージをバルクメッセージでＭＮ１に返信する。ここで、ＭＮ１がバルクＢＵメッセージを送信するインタフェースと、バルクＢＡメッセージを受信するインタフェースは任意であり、また、同じであっても異なってもよい。
次に、第１の実施の形態により、個々のＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]に対してパケットが届くこと（reachable）をＣＮ３が確認できることを説明する。
（１）では、ＭＮ１はＣｏＡ[1]〜[n]毎にユニークな各クッキーＫ１[1]〜[n]（Care of Init Cookie）を生成し、ＣＮ３に対し、各クッキーＫ１[1]〜[n]をそれぞれ含むＣｏＴｉ[1]〜[n]メッセージを個別に送信する。
（２）では、ＣＮ３はＣｏＴｉ[1]〜[n]メッセージを受け取ると、ＣｏＡ[1]〜[n]毎にユニークな各署名用トークンＴ１[1]〜[n]を生成し、ＭＮ１に対し、署名用トークンＴ１[1]〜[n]をそれぞれを含むＣｏＴ[1]〜[n]メッセージを個別に送信する。
（３）では、ＭＮ１はＣｏＴ[1]〜[n]メッセージを受け取ると、署名用トークンＴ１[1]〜[n]などからＣｏＡ[1]〜[n]に対して共通のバインディング管理キーＫbm(common)を生成し、このＫbm(common)と全てのＣｏＡ[1]〜[n]などから、ＣｏＡ[1]〜[n]に対して共通のＭＡＣ(common)を生成し、ＣＮ３に対し、この共通のＭＡＣ(common)と全てのＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]を含むバルクＢＵメッセージを送信する。
したがって、ＭＮ１がバルクＢＵメッセージをＣＮ３に送信しても、ＣＮ３は個々のＣｏＡ[1]，ＣｏＡ[2]〜ＣｏＡ[n]に対してreachableであると確認できる。なお、全てのＣｏＡについてreachableを問題にしない場合には、共通のＭＡＣ(common)を生成する際に用いるＣｏＡは全てではなく、１以上の代表ＣｏＡを用いてもよい。その例を以下に示す（代表ＣｏＡ＝ＣｏＡ[5]，ＣｏＡ[2]，ＣｏＡ[7]）。
ＭＡＣ：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[5]，ＣＮアドレス，ＢＵ）
ＭＡＣ：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[2]，ＣｏＡ[7]，ＣＮアドレス，ＢＵ）
＜第２の実施の形態＞
次に、図３、図４を参照して第２の実施の形態について説明する。図３は、本発明に係る通信システムの第２の実施の形態の構成とメッセージを示す説明図、図４は第２の実施の形態の通信シーケンスを示す説明図である。第２の実施の形態では、ＣｏＴｉ、ＣｏＴをバルクメッセージで送信し、ＢＵメッセージをＣｏＡ毎に個別に送信する。
（１）ＣｏＴｉ（ＨｏＴｉ）
まず、ＭＮ１はホームアドレス用のクッキーＫ０（Home Init Cookie）と気付けアドレスＣｏＡ[1]〜[n]用の各クッキーＫ１[1]〜[n]（Care of Init Cookie）を生成する。そして、ＭＮ１はＣＮ３に対し、クッキーＫ０を含むＨｏＴｉメッセージをＨＡ２経由で送信するとともに、クッキーＫ１[1]〜[n]及びＣｏＡ[1]〜[n]を含むバルクＣｏＴｉメッセージを直接送信する。バルクＣｏＴｉメッセージのパケットの送信元アドレスは、ＣｏＡ[1]〜[n]の代表ＣｏＡである。
（２）ＣｏＴ（ＨｏＴ）
ＣＮ３はあらかじめ、秘密鍵Ｋcnとノンス（nonce）テーブルを保持し、バルクＣｏＴｉメッセージを受け取ると、秘密鍵Ｋcnと、ＨｏＡ、ＣｏＡ[1]〜[n]、nonce（Ｎｉ、Ｎｊ）のハッシュ値から、以下のようにホームアドレスＨｏＡ用の署名用トークンＴ０と気付けアドレスＣｏＡ[1]〜[n]用の各署名用トークンＴ１[1]〜[n]を生成する。なお、ＣｏＡ[1]〜[n]のＮｊは、共通であっても、また、別個に異なるものでもよい。
Ｔ０ ：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＨｏＡ，Ｎｉ、０））
Ｔ１[1]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[1]，Ｎｊ、０））
Ｔ１[2]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[2]，Ｎｊ、０））
・・・・・
Ｔ１[n]：ＨＭＡＣ＿ＳＨＡ１（Ｋcn，（ＣｏＡ[n]，Ｎｊ、０））
そして、ＣＮ３はＭＮ１に対し、以下のようにクッキーＫ０、署名用トークンＴ０、ノンステーブルインデックスｉなどを含むＨｏＴメッセージをＨＡ２経由で送信するとともに、クッキーＫ１[1]〜[n]、署名用トークンＴ１[1]〜[n]、ノンステーブルインデックスｊなどを含むバルクＣｏＴメッセージを直接送信する。
ＨｏＴ：（Ｋ０，Ｔ０，ｉ・・・）
ＣｏＴ：（Ｋ１[1]，Ｋ１[2]〜Ｔ１[n]，Ｔ１[1]，Ｔ１[2]〜Ｔ１[n]，ｊ・・・）
ここで、ＭＮ１がバルクＣｏＴｉメッセージを送信するインタフェースと、バルクＣｏＴメッセージを受信するインタフェースは任意であり、また、同じであっても異なってもよい。
（３）ＭＮ１はトークンのハッシュ値からバインディング管理キーＫbm[1]、Ｋbm[2]〜Ｋbm[n]をそれぞれ生成し、
Ｋbm[1]：ＳＨＡ１（Ｔ０，Ｔ１[1]）
Ｋbm[2]：ＳＨＡ１（Ｔ０，Ｔ１[2]）
・・・・・
Ｋbm[n]：ＳＨＡ１（Ｔ０，Ｔ１[n]）
次いで、このＫbm[1]、Ｋbm[2]〜Ｋbm[n]、ＣｏＡ[1]、ＣｏＡ[2]〜[n]、ＣＮアドレス、ＢＵのハッシュ値から以下のようにして署名用のＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]を生成する。
ＭＡＣ[1]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[1]，ＣＮアドレス，ＢＵ）
ＭＡＣ[2]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[2]，ＣＮアドレス，ＢＵ）
・・・・・
ＭＡＣ[n]：ＨＭＡＣ＿ＳＨＡ１（Ｋbm，（ＣｏＡ[n]，ＣＮアドレス，ＢＵ）
そして、ＭＮ１は、ＣＮ３に対する個々のＢＵメッセージＢＵ[1]、ＢＵ[2]〜ＢＵ[n]として、以下の内容を含むメッセージを生成し、送信する。
ＢＵ[1]（ＨｏＡ，ＣｏＡ[1]，ｉ，ｊ，seq＃，ＭＡＣ[1]）
ＢＵ[2]（ＨｏＡ，ＣｏＡ[2]，ｉ，ｊ，seq＃，ＭＡＣ[2]）
・・・・・
ＢＵ[n]（ＨｏＡ，ＣｏＡ[n]，ｉ，ｊ，seq＃，ＭＡＣ[n]）
（４）ＣＮ３はＭＮ１と別個に、また、ＭＮ１と同様に、Ｋbm[1]、Ｋbm[2]〜Ｋbm[n]をそれぞれ生成し、次いでこのＫbm[1]、Ｋbm[2]〜Ｋbm[n]などからＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]をそれぞれ生成して個々のＢＵメッセージ内のＭＡＣ[1]、ＭＡＣ[2]〜ＭＡＣ[n]と比較し、一致した場合に「認証ＯＫ」とし、個々のバインディング確認（ＢＡ）メッセージをＭＮ１に返信する。
（５）ＭＮ１は個々のＢＵを受け取ると、ＣＮ３が個々のＣｏＡ[1]、ＣｏＡ[2]〜ＣｏＡ[n]に対してパケットが届くこと（reachable）を確認できるように、ＣｏＡ[1]、ＣｏＡ[2]〜ＣｏＡ[n]に対して共通のreachableチェックキーＫrc(common)を生成し、ＣＮ３に対し、Ｋrc(common)を含むバルクＢＡackメッセージを送信する。
Ｋrc(common)：ＳＨＡ１（Ｔ０，Ｔ１[1]，Ｔ１[2]〜[n]）
ここで、このＫrc(common)は、第１の実施の形態において全てのトークンのハッシュ値から生成した、ＣｏＡ[1]〜[n]に対して共通のバインディング管理キーＫbm(common)と同じである。このため、第２の実施の形態においても同様に、バルクＣｏＴｉメッセージ、バルクＣｏＴメッセージを送信しても、ＣＮ３は個々のＣｏＡ[1]、ＣｏＡ[2]〜ＣｏＡ[n]に対してreachableであると確認できる。
＜第１、第２の実施の形態の考察＞
図５はＣｏＴｉ、ＣｏＴ、ＢＵメッセージと個別（Ind）、バルク（Bulk）の組み合わせを示す。まず、reachabilityとAmplificationについて考察する。ここでreachabilityとは、各ＣｏＡのインタフェースへパケットが到達することが確認できることを意味する。また、Amplificationとは、問い合わせなどのメッセージに対して、その応答のメッセージの方が多くなる（アンプリファイされる）ことを意味し、輻輳を引き起こしやすくするためアンプリファイされないことが望ましい。
・ケース１（ＣｏＴｉ＝Bulk，ＣｏＴ＝Bulk，ＢＵ＝Bulk）は、ＭＮの各インタフェースに対するＣＮからの到達確認を一度も行っていないのでこのままではreachabilityを満足しない。これらのバルクメッセージに加えて個別ＢＡとバルクＢＡackを用いることでreachabilityを満足することはできる（バルクＢＡackの代わりに個別ＢＡackを用いてもreachabilityを満足することはできるがメッセージ数が多い）。ところが、バルクＢＵが個別ＢＡとしてアンプリファイされるので、ＮＧである。
・ケース２（ＣｏＴｉ＝Bulk，ＣｏＴ＝Bulk，ＢＵ＝Ind：第２の実施の形態）は、個別ＢＡとバルクＢＡackがreachabilityを満足するので、ＯＫである。
・ケース３（ＣｏＴｉ＝Bulk，ＣｏＴ＝Ind，ＢＵ＝Bulk）は、１つのＣｏＴｉにより多くのＣｏＴが発生する、すなわちアンプリファイされるので、ＮＧである。
・ケース４（ＣｏＴｉ＝Bulk，ＣｏＴ＝Ind，ＢＵ＝Ind）も、１つのＣｏＴｉにより多くのＣｏＴが発生する、すなわちアンプリファイされるので、ＮＧである。
・ケース５（ＣｏＴｉ＝Ind，ＣｏＴ＝Bulk，ＢＵ＝Bulk）は、ＭＮの各インタフェースに対するＣＮからの到達確認を一度も行っていないのでこのままではreachabilityを満足しない。これらのバルクメッセージに加えて個別ＢＡとバルクＢＡackを用いることでreachabilityを満足することはできる（バルクＢＡackの代わりに個別ＢＡackを用いてもreachabilityを満足することはできるがメッセージ数が多い）。ところが、バルクＢＵが個別ＢＡとしてアンプリファイされるので、ＮＧである。
・ケース６（ＣｏＴｉ＝Ind，ＣｏＴ＝Bulk，ＢＵ＝Ind）は、個別ＢＡとバルクＢＡackがreachabilityを満足するので、ＯＫである。
・ケース７（ＣｏＴｉ＝Ind，ＣｏＴ＝Ind，ＢＵ＝Bulk：第１の実施の形態）は、reachabilityが個別ＣｏＴ、バルクＢＵにより安全にチェックされるので、ＯＫである。
・ケース８（ＣｏＴｉ＝Ind，ＣｏＴ＝Ind，ＢＵ＝Ind：図６，課題）は、ＯＫである。
次に、上記のＯＫであったケース２、６、７、８のメッセージ数（及びメッセージのラウンドトリップ回数）について考察する。下記でｎはＣｏＡの数を示す。
・ケース８：
ｎＣｏＴｉ＋ｎＣｏＴ＋ｎＢＵ＝３ｎ messages, 1.5 round trips
・ケース２：
１ＣｏＴｉ＋１ＣｏＴ＋ｎＢＵ＋ｎＢＡ＋１ＢＡack＝２ｎ＋３ messages, 2.5 round trips
・ケース６：
ｎＣｏＴｉ＋１ＣｏＴ＋ｎＢＵ＋ｎＢＡ＋１ＢＡack＝３ｎ＋２ messages, 2.5 round trips
・ケース７：
ｎＣｏＴｉ＋ｎＣｏＴ＋１ＢＵ＝２ｎ＋１ messages, 1.5 round trips
以上により、ケース６のメッセージ数はケース８（図６，課題）より多くなるので良い解決策とは言えない。ケース７（第１の実施の形態）のメッセージ数は、ｎ＞２の場合、ケース８（図６，課題）より少なくなるので、最善の解決策である。ケース２（第２の実施の形態）は、ケース８（図６，課題）よりラウンドトリップの回数が多くはなるが、ｎ＞４の場合、メッセージ数が少なくなり改善されている。
本発明は、モバイルノードと相手先の通信ノードとの間で認証を行うＲＲ手続を行う場合のメッセージ数を減少させることができるという効果を有し、Ｍｏｎａｍｉ６などに利用することができる。
本発明に係る通信システムの第１の実施の形態の構成とメッセージを示す説明図 第１の実施の形態の通信シーケンスを示す説明図 本発明に係る通信システムの第２の実施の形態の構成とメッセージを示す説明図 第２の実施の形態の通信シーケンスを示す説明図 第１、第２の実施の形態を考察した説明図 従来のＭｏｎａｍｉ６におけるバルクＢＵを示す説明図 本発明が解決しようとする課題を示す説明図

Claims (8)

  1. 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法であって、
    前記モバイルノードが、前記複数のインタフェースの各々からそれぞれ第１のメッセージを個々に前記相手先の通信ノードに送信するステップと、
    前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で前記モバイルノードに送信するステップと、
    前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信するステップと、
    前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証するステップとを、
    有する通信方法。
  2. 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムであって、
    前記モバイルノードが、前記複数のインタフェースの各々からそれぞれ第１のメッセージを個々に前記相手先の通信ノードに送信する手段と、
    前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で前記モバイルノードに送信する手段と、
    前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段と、
    前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを、
    有する通信システム。
  3. 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記モバイルノードであって、
    前記複数のインタフェースの各々からそれぞれ第１のメッセージを前記相手先の通信ノードに個々に送信する手段と、
    前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で自身に送信した場合に、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段とを有し、
    前記相手先の通信ノードが、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証するようにしたモバイルノード。
  4. 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、
    前記モバイルノードが、前記複数のインタフェースの各々からそれぞれ第１のメッセージを自身に個々に送信した場合、前記複数のインタフェースの各々から送信された複数の前記第１のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを複数の第２のメッセージの各々で前記モバイルノードに送信する手段と、
    前記モバイルノードが、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク・バインディング・アップデートメッセージを自身に送信した場合、前記バルク・バインディング・アップデートメッセージ内の前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを、
    有する通信ノード。
  5. 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信方法であって、
    前記モバイルノードが、前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを前記相手先の通信ノードに送信するステップと、
    前記相手先の通信ノードが、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで前記モバイルノードに送信するステップと、
    前記モバイルノードが、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを前記相手先の通信ノードに送信するステップと、
    前記相手先の通信ノードが、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバイルノードに送信するステップと、
    前記モバイルノードが、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを前記相手先の通信ノードに送信するステップと、
    前記相手先の通信ノードが、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断するステップとを、
    有する通信方法。
  6. 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムであって、
    前記モバイルノードが、前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを前記相手先の通信ノードに送信する手段と、
    前記相手先の通信ノードが、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで前記モバイルノードに送信する手段と、
    前記モバイルノードが、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段と、
    前記相手先の通信ノードが、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバイルノードに送信する手段と、
    前記モバイルノードが、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを前記相手先の通信ノードに送信する手段と、
    前記相手先の通信ノードが、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断する手段とを、
    有する通信システム。
  7. 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記モバイルノードであって、
    前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを前記相手先の通信ノードに送信する手段と、
    前記相手先の通信ノードが、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで自身に送信した場合、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを前記相手先の通信ノードに送信する手段と、
    前記相手先の通信ノードが、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを自身に送信した場合、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを前記相手先の通信ノードに送信する手段とを有し、
    前記相手先の通信ノードが、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断するようにしたモバイルノード。
  8. 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが割り当てられているモバイルノードを相手先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、
    前記モバイルノードが、前記複数のインタフェースの１つから前記複数の気付けアドレスを含む第１のバルクメッセージを自身に送信した場合、前記第１のバルクメッセージを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数の気付けアドレスに対して共通の第２のバルクメッセージで前記モバイルノードに送信する手段と、
    前記モバイルノードが、前記第２のバルクメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証コードをそれぞれ含む複数のバインディング・アップデートメッセージを自身に送信した場合、前記複数のバインディング・アップデートメッセージ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバイルノードに送信する手段と、
    前記モバイルノードが、前記各バインディング確認メッセージを受信して、前記複数の第２のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルク確認メッセージを自身に送信した場合、前記バルク確認メッセージ内の前記複数の気付けアドレスの各々に対して到達可能か否かを判断する手段とを、
    有する通信ノード。
JP2008542172A 2006-11-02 2007-11-01 通信方法、通信システム、モバイルノード及び通信ノード Expired - Fee Related JP4778565B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008542172A JP4778565B2 (ja) 2006-11-02 2007-11-01 通信方法、通信システム、モバイルノード及び通信ノード

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2006299468 2006-11-02
JP2006299468 2006-11-02
JP2008542172A JP4778565B2 (ja) 2006-11-02 2007-11-01 通信方法、通信システム、モバイルノード及び通信ノード
PCT/JP2007/071297 WO2008053955A1 (fr) 2006-11-02 2007-11-01 Procédé de communication, système de communication, nœud mobile et nœud de communication

Publications (2)

Publication Number Publication Date
JPWO2008053955A1 JPWO2008053955A1 (ja) 2010-02-25
JP4778565B2 true JP4778565B2 (ja) 2011-09-21

Family

ID=39344295

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008542172A Expired - Fee Related JP4778565B2 (ja) 2006-11-02 2007-11-01 通信方法、通信システム、モバイルノード及び通信ノード

Country Status (5)

Country Link
US (1) US20100275020A1 (ja)
EP (1) EP2079201A1 (ja)
JP (1) JP4778565B2 (ja)
CN (1) CN101536562A (ja)
WO (1) WO2008053955A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8370503B2 (en) * 2008-05-02 2013-02-05 Futurewei Technologies, Inc. Authentication option support for binding revocation in mobile internet protocol version 6
US20100054217A1 (en) * 2008-08-26 2010-03-04 Telefonaktiebolaget Lm Ericsson (Publ) Registration of multiple care-of-addresses
WO2014198745A1 (en) * 2013-06-12 2014-12-18 Telecom Italia S.P.A. Mobile device authentication in heterogeneous communication networks scenario
CN110035037B (zh) * 2018-01-11 2021-09-17 华为技术有限公司 安全认证方法、相关设备及系统
CN112232817A (zh) * 2018-10-25 2021-01-15 创新先进技术有限公司 基于区块链的交易处理方法及装置、电子设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060251044A1 (en) * 2005-04-22 2006-11-09 Wassim Haddad Mobility support for multihome nodes

Also Published As

Publication number Publication date
WO2008053955A1 (fr) 2008-05-08
CN101536562A (zh) 2009-09-16
EP2079201A1 (en) 2009-07-15
JPWO2008053955A1 (ja) 2010-02-25
US20100275020A1 (en) 2010-10-28

Similar Documents

Publication Publication Date Title
EP1875710B1 (en) System, associated methods and apparatus for securing prefix-scoped binding updates
KR100679882B1 (ko) 사설 네트워크와 로밍 모바일 단말 사이의 통신
KR100759727B1 (ko) 승인된 통신 방법
US8447979B2 (en) Method and apparatus for binding update between mobile node and correspondent node
KR101414711B1 (ko) 이동 ｉｐ 키를 제공하기 위한 방법 및 시스템
JP2009516435A (ja) 複数鍵暗号化生成アドレスを使ったモバイルネットワークのためのセキュアな経路最適化
EP1738560A1 (en) Securing home agent to mobile node communication with ha-mn key
JP2007036641A (ja) ホームエージェント装置、及び通信システム
JP5044690B2 (ja) Ｉｐモビリティシステムのための動的な外部エージェント−ホーム・エージェント・セキュリティ・アソシエーション割当て
JP5250634B2 (ja) 移動通信ネットワークにおいて使用するための方法及び装置
JP4778565B2 (ja) 通信方法、通信システム、モバイルノード及び通信ノード
US7756073B2 (en) Method for updating a routing entry
EP2449800B1 (en) Methods and systems for mobile ip route optimization
JPWO2009011120A1 (ja) アドレス生成方法、アドレス生成システム、通信装置、通信方法、通信システム及び相手先通信装置
US8750303B2 (en) Mobility signaling delegation
JPWO2009066439A1 (ja) 通信方法、通信システム、モバイルノード及び通信ノード
You et al. caTBUA: context‐aware ticket‐based binding update authentication protocol for trust‐enabled mobile networks
Park et al. Securing 6LoWPAN neighbor discovery
CN102484659A (zh) 用于生成移动ip网络中密码生成地址的方法和网络节点
Taha et al. Secure IP mobility management for VANET
Jara et al. Secure mobility management scheme for 6lowpan id/locator split architecture
Basak et al. Security in Network Mobility (NEMO): Issues, Solutions, Classification, Evaluation, and Future Research Directions.
Taha et al. Multihop mobile authentication for pmip networks
You et al. Comments on a one-way hash chain based authentication for fmipv6
JP2009246531A (ja) モバイル通信システム、モバイルルータ、ホームエージェント、通信端末及びモバイル通信方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100714

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110610

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110701

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140708

Year of fee payment: 3

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees