JP2009525708A - プロトコルリンクレイヤ - Google Patents
プロトコルリンクレイヤ Download PDFInfo
- Publication number
- JP2009525708A JP2009525708A JP2008553515A JP2008553515A JP2009525708A JP 2009525708 A JP2009525708 A JP 2009525708A JP 2008553515 A JP2008553515 A JP 2008553515A JP 2008553515 A JP2008553515 A JP 2008553515A JP 2009525708 A JP2009525708 A JP 2009525708A
- Authority
- JP
- Japan
- Prior art keywords
- node
- link
- packet
- layer
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/325—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the network layer [OSI layer 3], e.g. X.25
-
- 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/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
-
- 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
リンクはソフトウェア抽象化であり、このソフトウェア抽象化は、2つのCoCoノードの間の直接的な接続手段を表わす。リンクレイヤは、隣接するCoCoデバイスの存在を検出し、そしてこれらのデバイスへのリンクを設定する。プロトコル抽象化レイヤは、ネットワークインターフェースに到着するデータフレームを、CoCoプロトコルスィートによって使用されるパケットオブジェクトに変換する。
Description
関連出願の相互参照
本出願は、2006年2月1日出願の「プロトコルリンクレイヤ」と題する米国仮特許出願第60/763,959号の利益を主張し、そして2006年2月1日出願の「プロトコル回線レイヤ」と題する米国仮特許出願第60/763,977号、及び2006年2月1日出願の「CSMA方式伝送媒体における輻輳管理及び遅延予測」と題する米国仮特許出願第60/764,013号に関連する。
本出願は、2006年2月1日出願の「プロトコルリンクレイヤ」と題する米国仮特許出願第60/763,959号の利益を主張し、そして2006年2月1日出願の「プロトコル回線レイヤ」と題する米国仮特許出願第60/763,977号、及び2006年2月1日出願の「CSMA方式伝送媒体における輻輳管理及び遅延予測」と題する米国仮特許出願第60/764,013号に関連する。
コンピュータをネットワーク化することによりデータをコンピュータ間で数十年間に亘って授受してきている。一つの重要なネットワークであるインターネットは、通信チャネルで相互接続される非常に多くのコンピュータ及びコンピュータネットワークを含む。インターネットは、電子商取引、電子メールのような情報交換、情報の抽出及び調査の実施などを含む種々の理由により使用される。多くの規格が、情報をインターネット経由で授受するために設定され、規格として、電子メール、ゴーファー(Gopher),及びワールドワイドウェブ(WWW)を挙げることができる。WWWサービスによって、サーバコンピュータシステム(すなわち、ウェブサーバまたはウェブサイト)は情報をグラフィカルなウェブページの形でリモートクライアントコンピュータシステムに送信することができる。従って、リモートクライアントコンピュータシステムはウェブページを表示することができる。WWWの各リソース(例えば、コンピュータまたはウェブページ)は、ユニフォームリソースロケータ(URL)によって一意に特定することができる。特定のウェブページを閲覧するために、クライアントコンピュータシステムは、当該ウェブページに対応するURLをリクエスト(例えば、ハイパーテキスト転送プロトコル(HTTP)リクエスト)として指定する。リクエストは、ウェブページをサポートするウェブサーバに転送される。当該ウェブサーバがリクエストを受信すると、サーバはリクエストされたウェブページをクライアントコンピュータシステムに送信する。クライアントコンピュータシステムが当該ウェブページを受信すると、クライアントコンピュータシステムは通常、ブラウザを使用してウェブページを表示する。ブラウザは通常、ウェブページをリクエストし、そして表示する特定用途向けプログラムである。
現在、ウェブページは多くの場合、ハイパーテキストマークアップ言語(HTML)を使用して記述される。HTMLには一連の標準のタグが使用され、これらのタグは、ウェブページを表示する方法について記述する。ユーザがリクエストをブラウザに対して行なってウェブページを表示させる場合、ブラウザはリクエストをサーバコンピュータシステムに送信し、サーバコンピュータシステムに、ウェブページを記述するHTMLドキュメントをクライアントコンピュータシステムに転送させる。リクエストされたHTMLドキュメントをクライアントコンピュータシステムが受信すると、ブラウザは、HTMLドキュメントに記述されたウェブページを表示する。HTMLドキュメントは種々のタグを含み、これらのタグで、テキスト、グラフィックス、コントロール、及び他の機能の表示を制御する。HTMLドキュメントには、当該サーバコンピュータシステムで、または他のサーバコンピュータシステムで利用することができる他のウェブページのURLが含まれる。
拡張可能マークアップ言語(XML)及びワイヤレスアクセスプロトコル(WAP)のような新規のプロトコルが存在する。XMLはHTMLよりも高いフレキシビリティを持つ。WAPは種々の機能の中でもとりわけ、ウェブページを、携帯電話機及び携帯型コンピュータ(例えばPDA)のような携帯型無線機器で閲覧する機能を実現する。これらのプロトコルの全てが、情報を人々に種々のデータ処理装置を介して提供する手段を容易にするように機能する。データをデータ処理装置の間で授受する多くの他のプロトコル及び手段が継続的に開発されることにより、情報の授受が更に容易になる。
リンクコンセプト
リンクはソフトウェア抽象化であり、このソフトウェア抽象化は、2つのCoCoノードの間の直接的な接続手段を表わす。リンクレイヤの基本タスクは、隣接するCoCoデバイスの存在を検出し、そしてこれらのデバイスへのリンクを設定することである。
リンクはソフトウェア抽象化であり、このソフトウェア抽象化は、2つのCoCoノードの間の直接的な接続手段を表わす。リンクレイヤの基本タスクは、隣接するCoCoデバイスの存在を検出し、そしてこれらのデバイスへのリンクを設定することである。
リンクレイヤプロトコル動作に関する記述
リンク設定では、従来の3ウェイハンドシェークプロトコル(“hello,”,“hello−ack,”,及び“final−ack,”を含むパケット;[ISI]を参照)に変更を加えたプロトコルを用いる。リンク設定では、符号化方式の合意を行ない、そしてデフィー・ヘルマン(Diffie−Hellman)キー交換を実行することにより、リンク経由で送信される全ての通信を暗号化チェックサム[S]によって検証することができる。これにより、識別情報の一貫性が確保される。すなわち、或るノードは、リンク経由で受信する全てのパケットが、当該ノードが当該リンクを設定したときの相手方のノードから送信されたパケットであることについて保証される。
リンク設定では、従来の3ウェイハンドシェークプロトコル(“hello,”,“hello−ack,”,及び“final−ack,”を含むパケット;[ISI]を参照)に変更を加えたプロトコルを用いる。リンク設定では、符号化方式の合意を行ない、そしてデフィー・ヘルマン(Diffie−Hellman)キー交換を実行することにより、リンク経由で送信される全ての通信を暗号化チェックサム[S]によって検証することができる。これにより、識別情報の一貫性が確保される。すなわち、或るノードは、リンク経由で受信する全てのパケットが、当該ノードが当該リンクを設定したときの相手方のノードから送信されたパケットであることについて保証される。
一旦、リンクが設定されると、リンクレイヤでは次の処理が行なわれる。
・パケットをネットワークインターフェースレイヤと、当該レイヤよりも上位のプロトコルレイヤ(ルーティングレイヤ及び回線レイヤ)との間で授受する。
・サービス品質(QoS)統計をモニタリングし、そしてこれらのサービス品質統計を上位のプロトコルレイヤにレポートする。
・マルチキャストを、単一ネットワークインターフェース経由の冗長なパケット送信を抑圧することによりサポートする。
・パケットサイズがネットワークインターフェースの最大送信単位(MTU)を超える場合にフラグメンテーションを実行する。
・無効リンクを閉鎖して、システムリソースを新規のリンクリクエストに開放する。
・パケットをネットワークインターフェースレイヤと、当該レイヤよりも上位のプロトコルレイヤ(ルーティングレイヤ及び回線レイヤ)との間で授受する。
・サービス品質(QoS)統計をモニタリングし、そしてこれらのサービス品質統計を上位のプロトコルレイヤにレポートする。
・マルチキャストを、単一ネットワークインターフェース経由の冗長なパケット送信を抑圧することによりサポートする。
・パケットサイズがネットワークインターフェースの最大送信単位(MTU)を超える場合にフラグメンテーションを実行する。
・無効リンクを閉鎖して、システムリソースを新規のリンクリクエストに開放する。
他のプロトコルレイヤとの関連におけるリンクレイヤ
図1は、CoCoプロトコルスィートの他のレイヤに対するリンクレイヤの関係を示している。CoCoプロトコルスィートレイヤは、図1の暗い背景に記された斜体文字で示される。
図1は、CoCoプロトコルスィートの他のレイヤに対するリンクレイヤの関係を示している。CoCoプロトコルスィートレイヤは、図1の暗い背景に記された斜体文字で示される。
ルーティングレイヤ、回線レイヤ、及びネーミングシステムレイヤに関する更なる詳細は、[BLMS],[BMV],及び[BELM]にそれぞれ記載されている。ネットワークインターフェースレイヤは、イーサネットカードのような物理ネットワークデバイスに対応したオペレーティングシステムのデバイスドライバである。
リンクレイヤのコンポーネント
図2は、CoCoプロトコルスィートにおける種々のレイヤの関係を示すブロック図である。リンクレイヤはネットワークインターフェースレイヤに接続され、そして次のコンポーネントにより構成される。
・ネットワークインターフェースに到着する着信データフレームを、CoCoプロトコルスィートによって使用されるパケットオブジェクトに変換するプロトコル抽象化レイヤ(PAL)。
・隣接ノードをつなぐリンクをCoCoネットワークにおいて設定するリンク設定サブレイヤ。
・データを設定リンクで転送するリンクデータサブレイヤ。
・リンク品質をモニタリングするQoSハンドラー。
図2は、CoCoプロトコルスィートにおける種々のレイヤの関係を示すブロック図である。リンクレイヤはネットワークインターフェースレイヤに接続され、そして次のコンポーネントにより構成される。
・ネットワークインターフェースに到着する着信データフレームを、CoCoプロトコルスィートによって使用されるパケットオブジェクトに変換するプロトコル抽象化レイヤ(PAL)。
・隣接ノードをつなぐリンクをCoCoネットワークにおいて設定するリンク設定サブレイヤ。
・データを設定リンクで転送するリンクデータサブレイヤ。
・リンク品質をモニタリングするQoSハンドラー。
図3は、プロトコルのインターフェースを含むリンクレイヤプロトコルの更なる詳細を示している。図3の矢印は、インターフェースの一部である関数コールを表わす。レイヤAからレイヤBに向かう矢印は、レイヤBにおけるプロシージャまたは関数がレイヤAから呼び出されることを示す。矢印の尾の部分の円は、或る値をコーラに返す機能を示す。
リンクレイヤインターフェース
リンクレイヤインターフェースは次の関数を提供し、これらの関数をルーティングレイヤ及び回線レイヤが使用してリンクの有無を判断し、そしてパケットをリンク経由で送信し、かつ受信する。
リンクレイヤインターフェースは次の関数を提供し、これらの関数をルーティングレイヤ及び回線レイヤが使用してリンクの有無を判断し、そしてパケットをリンク経由で送信し、かつ受信する。
LinkUp(link)
リンクレイヤはLinkUp(link)を呼び出して、回線レイヤ及びルーティングレイヤにリンクが開放されたことを通知する。
リンクレイヤはLinkUp(link)を呼び出して、回線レイヤ及びルーティングレイヤにリンクが開放されたことを通知する。
LinkDown(link)
リンクレイヤはLinkDown(link)を呼び出して、回線レイヤ及びルーティングレイヤにリンクが閉鎖されたことを通知する。
リンクレイヤはLinkDown(link)を呼び出して、回線レイヤ及びルーティングレイヤにリンクが閉鎖されたことを通知する。
Receive(packet, link)
リンクレイヤはReceive(packet, link)を呼び出して、回線レイヤ及びルーティングレイヤに、パケットがリンク経由で到着したことを通知する。
リンクレイヤはReceive(packet, link)を呼び出して、回線レイヤ及びルーティングレイヤに、パケットがリンク経由で到着したことを通知する。
Send(packet, link)
回線レイヤまたはルーティングレイヤはSend(packet, link)を呼び出して、パケットをリンク経由で送信させる。
回線レイヤまたはルーティングレイヤはSend(packet, link)を呼び出して、パケットをリンク経由で送信させる。
GetQoS(link)
回線レイヤまたはルーティングレイヤはGetQoS(link)を呼び出して、所定のリンクに関連するQoS指標を取得させる。
回線レイヤまたはルーティングレイヤはGetQoS(link)を呼び出して、所定のリンクに関連するQoS指標を取得させる。
リンクレイヤのパケットタイプ
PALで着信データフレームを解析した後、当該レイヤはネットワークインターフェースヘッダを廃棄する。残っているデータはリンク設定パケットまたはリンクデータパケットのいずれかである。
・リンク設定パケット:リンク設定パケットは、リンクを設定するために必要な情報を含む。リンク設定パケットのパケットヘッダはリンク設定パケット全体である。リンク設定パケットには別のデータ部分が無い。リンク設定パケットはリンクレイヤ内でのみ使用される。
・リンクデータパケット:実際のユーザデータ(及び、上位のプロトコルレイヤに関連する全てのデータ)の他に、リンクデータパケットはデータパケット確認応答、データパケットフラグメンテーション、及び暗号化チェックサムをハンドリングする更に別のフィールドを含む。リンクデータパケットはルーティングレイヤ及び回線レイヤに転送される。
PALで着信データフレームを解析した後、当該レイヤはネットワークインターフェースヘッダを廃棄する。残っているデータはリンク設定パケットまたはリンクデータパケットのいずれかである。
・リンク設定パケット:リンク設定パケットは、リンクを設定するために必要な情報を含む。リンク設定パケットのパケットヘッダはリンク設定パケット全体である。リンク設定パケットには別のデータ部分が無い。リンク設定パケットはリンクレイヤ内でのみ使用される。
・リンクデータパケット:実際のユーザデータ(及び、上位のプロトコルレイヤに関連する全てのデータ)の他に、リンクデータパケットはデータパケット確認応答、データパケットフラグメンテーション、及び暗号化チェックサムをハンドリングする更に別のフィールドを含む。リンクデータパケットはルーティングレイヤ及び回線レイヤに転送される。
プロトコル抽象化レイヤ
リンクレイヤのプロトコル抽象化レイヤ(PAL)で、(イーサネットインターフェースまたは衛星インターフェースのような)ネットワークインターフェースに到着する着信データフレームを解析し、当該データを使用してCoCoヘッダ及びアドレス変換テーブルを作成し、次にネットワークインターフェースデータフレームのヘッダを廃棄する。ネットワークインターフェースヘッダが廃棄された後、残っているデータはリンク設定パケットまたはリンクデータパケットのいずれかである。リンクレイヤでこれらのパケットを分析し、そしてリンク設定パケットをリンク設定サブレイヤに、そしてリンクデータパケットをリンクデータサブレイヤに送信する。
リンクレイヤのプロトコル抽象化レイヤ(PAL)で、(イーサネットインターフェースまたは衛星インターフェースのような)ネットワークインターフェースに到着する着信データフレームを解析し、当該データを使用してCoCoヘッダ及びアドレス変換テーブルを作成し、次にネットワークインターフェースデータフレームのヘッダを廃棄する。ネットワークインターフェースヘッダが廃棄された後、残っているデータはリンク設定パケットまたはリンクデータパケットのいずれかである。リンクレイヤでこれらのパケットを分析し、そしてリンク設定パケットをリンク設定サブレイヤに、そしてリンクデータパケットをリンクデータサブレイヤに送信する。
要約すると、PALでは、
・データフレームをネットワークデバイスまたはネットワーク接続から取得する。
・関連情報を(通常、イーサネットカードのようなネットワークデバイスのデバイスドライバである)ネットワークインターフェースレイヤから取り出して格納したCoCoヘッダ及びアドレス変換テーブルを作成する。
・ネットワークインターフェースレイヤヘッダを削除し、そして廃棄する。
・変更済みパケットをリンク設定サブレイヤまたはリンクデータサブレイヤのいずれかに渡す。
・データフレームをネットワークデバイスまたはネットワーク接続から取得する。
・関連情報を(通常、イーサネットカードのようなネットワークデバイスのデバイスドライバである)ネットワークインターフェースレイヤから取り出して格納したCoCoヘッダ及びアドレス変換テーブルを作成する。
・ネットワークインターフェースレイヤヘッダを削除し、そして廃棄する。
・変更済みパケットをリンク設定サブレイヤまたはリンクデータサブレイヤのいずれかに渡す。
CoCoヘッダ及びアドレス変換テーブル
CoCoヘッダ及びアドレス変換テーブルは、ネットワークインターフェースレイヤのヘッダの代わりに用いられる。PALでは、CoCoヘッダ及びアドレス変換テーブルを、パケットをネットワークインターフェースから受信した後に作成する。フレームがいずれかの物理ネットワークインターフェースから到着すると、PALでフレームヘッダを読み取って、CoCoヘッダを構成し、そしてエントリを当該レイヤのアドレス変換テーブルに追加する。
CoCoヘッダ及びアドレス変換テーブルは、ネットワークインターフェースレイヤのヘッダの代わりに用いられる。PALでは、CoCoヘッダ及びアドレス変換テーブルを、パケットをネットワークインターフェースから受信した後に作成する。フレームがいずれかの物理ネットワークインターフェースから到着すると、PALでフレームヘッダを読み取って、CoCoヘッダを構成し、そしてエントリを当該レイヤのアドレス変換テーブルに追加する。
アドレス変換テーブルはメモリにのみ格納され、そしてPALでのみ使用される。PALで送信元アドレスをフレームヘッダから抽出し、そして当該アドレスを送信元ノードのユニバーサルノード識別子(UNI)に関連付けて、関連付けをアドレス変換テーブルに保存する。アドレス変換テーブルはノードが使用する物理トランスポートの各タイプに対応して作成される。従って、UNIはCoCoプロトコル全体で使用される。アドレス変換テーブルは、データがネットワークインターフェースレイヤに送信される場合にのみ必要になる(UNIに関する更なる情報については[BLMS]を参照されたい)。
CoCoヘッダのフォーマットは一定である−フォーマットは、パケットがどのタイプのインターフェースに到着するかどうかに関係なく同じである。CoCoヘッダはメモリに格納され、そして上位のプロトコルレイヤで利用することができる。ヘッダの構造を図4に示すが、各フィールドのビットサイズは括弧内に与えられる。
タイプフィールドには、CoCoヘッダに続くパケットのタイプ−リンク設定パケットまたはリンクデータパケットのいずれか−が記述される。暗号化フィールドには、パケットが暗号化されているかどうかが記述される。暗号化は、リンクが設定された後になるまで行なわれることがないので、全てのリンク設定パケットが暗号化されていない。全てのブロードキャストパケットも、複数のノードによって解読されることになるメッセージを暗号化することが難しいので暗号化されていない。パケットサイズフィールドは、CoCoヘッダに続くパケット全体のバイトサイズである。
CoCoノードは更に、CoCoヘッダを物理ネットワークインターフェース経由で送信して、パケット完全性のチェック手段として機能する。PALでCoCoヘッダを普通の方法で作成した後、結果として得られるCoCoヘッダは有線送信されているCoCoヘッダと比較チェックされる。これらのCoCoヘッダが一致しない場合、パケットは廃棄される。
PALがサポートするトランスポート
PALは、多数のネットワークインターフェースフォーマットをサポートし、ネットワークインターフェースフォーマットとして以下のフォーマットを挙げることができる。
・イーサネット(IEEE 802.3)
・トークンリング(IEEE 802.5)
・Wi−Fi(IEEE 802.11)
・同期光ネットワーク(SONET)
・非同期転送モード(ATM)
・衛星
他のトランスポート技術では、前に列挙したネットワークインターフェースフォーマットを使用するので、リンクレイヤも以下のフォーマットをサポートする。
・インターネットプロトコル(IP)
・転送制御プロトコル(TCP)
・ユーザデータグラムプロトコル(UDP)
・移動体通信用グローバルシステム(GSM)及び符号分割多重接続(CDMA)
・携帯デジタルパケットデータ(CDPD),汎用パケット無線サービス(GPRS)、及び1XRTT
PALは、当該レイヤがモジュールにより構成されるので、他のフォーマットをサポートするように容易に拡張することができる。
PALは、多数のネットワークインターフェースフォーマットをサポートし、ネットワークインターフェースフォーマットとして以下のフォーマットを挙げることができる。
・イーサネット(IEEE 802.3)
・トークンリング(IEEE 802.5)
・Wi−Fi(IEEE 802.11)
・同期光ネットワーク(SONET)
・非同期転送モード(ATM)
・衛星
他のトランスポート技術では、前に列挙したネットワークインターフェースフォーマットを使用するので、リンクレイヤも以下のフォーマットをサポートする。
・インターネットプロトコル(IP)
・転送制御プロトコル(TCP)
・ユーザデータグラムプロトコル(UDP)
・移動体通信用グローバルシステム(GSM)及び符号分割多重接続(CDMA)
・携帯デジタルパケットデータ(CDPD),汎用パケット無線サービス(GPRS)、及び1XRTT
PALは、当該レイヤがモジュールにより構成されるので、他のフォーマットをサポートするように容易に拡張することができる。
リンク設定サブレイヤ
リンク設定サブレイヤは以下の機能を実行する。:
・他のノードの存在を認識し、そして認識を維持する。
・通信範囲内のノードへのリンクを設定する。
・各リンクに用いられるデフィー・ヘルマンキーを生成する。
・各リンクに適用される符号化方式を実装する。
・ワークトークンを計算し、そして検証してサービス拒否攻撃を防止する。
・各リンクの往復時間をモニタリングする。
・リンクが無効になる時点を判断し、そしてリンクを閉鎖する。
リンク設定サブレイヤは以下の機能を実行する。:
・他のノードの存在を認識し、そして認識を維持する。
・通信範囲内のノードへのリンクを設定する。
・各リンクに用いられるデフィー・ヘルマンキーを生成する。
・各リンクに適用される符号化方式を実装する。
・ワークトークンを計算し、そして検証してサービス拒否攻撃を防止する。
・各リンクの往復時間をモニタリングする。
・リンクが無効になる時点を判断し、そしてリンクを閉鎖する。
リンク設定サブレイヤは、反復する2フェーズプロセスをノードに関して使用して情報を授受することにより前述の機能を実現する。
リンク設定パケット
リンク設定サブレイヤは、図5に示すような、リンク設定パケットと表記される単一のパケットフォーマットを利用する。
リンク設定パケット
リンク設定サブレイヤは、図5に示すような、リンク設定パケットと表記される単一のパケットフォーマットを利用する。
リンク設定パケットは、ノードが当該ノードの存在、及び識別情報を他のノードに通告し、そして同時に他のノードに、当該ノードがこのような通告を他のノードから受信したことを通知する機構を実現する。従って、或る状況では、リンク設定パケットはハローパケットとして機能し、そして他の状況では、リンク設定パケットは確認応答またはackパケットとして機能する。
ノードをネットワーク上で動的に追加し、そして削除する操作を容易にするために、各ノードはリンク設定パケットを所定の期間でブロードキャストする。この構成によって、リンク設定パケットを、同じパケットの中のハロー及び確認応答の両方として機能させることもできる。この所定の期間はハローインターバルと呼ばれ、そして通常1秒である。確認応答は発信ハローパケットに相乗りさせる。各ノードは、ack−setと表記されるノード群のセットを維持し、当該ノード群のセットから約5〜10秒であるack−intervalと表記される所与の期間内にハロー受信する。
ack−intervalはリンクタイムアウトパラメータである。ノードAがハローパケットをノードBからack−intervalよりも長い期間の間に全く受信することがない場合、ノードAはノードBをノードAのack−setから削除し、そしてこの時点以降、ノードAの発信ハローメッセージでノードBに確認応答を送信することはない。
セキュリティ攻撃によってパケットフラッドが発生する現象を防止するために、各ノードは、全てのリンク設定パケットに含めるワークトークンを計算する。ワークトークンはワークトークン有効期間(WTVI)と呼ばれる期間中に有効であり、ワークトークン有効期間は通常、ハローインターバルよりも長いが確認応答区間よりも短い時間長である。ワークトークンの有効期間が満了すると(ワークトークン有効期間WTVIに従って)、ノードは、新規のワークトークンを当該ノードの次のリンク設定パケットを送出する前に計算する必要がある。 リンクレイヤで使用する第4期間がデフィー・ヘルマンキャッシュインターバル(DHCI)であり、このキャッシュインターバルはワークトークン有効期間WTVIよりも長くする必要があり、かつ確認応答区間よりも長くする必要もある。DHCIは、ノードAがノードBと通信するために使用するデフィー・へルマンキーのキャッシュバージョンを保持する時間長である。デフィー・へルマンキーの計算には多くのリソースが必要となるので、ノードBがノードAへのリンクを再設定しようとする場合には、リンクが中断された後でもキーのキャッシュバージョンを保持しておくことは有用である。ノードAがリンク設定パケットをノードBからDHCI内に受信しない場合、ノードAはそのキーのキャッシュコピーを消去する。
リンク設定パケット−セクションによって分離され−図5に示され、破線は繰り返すことができるパケットのセクションを示し、そしてカッコ内の数字は各フィールドのビットサイズを示す。
リンク設定パケットは次のセクションを含む。
・リンク設定フィールド
・1セットの応答確認及び関連フィールド(ack−set)
・サポートされる符号化方式のリスト
・ノードの公開キー
リンク設定パケットのリンク設定セクション
図6に示すリンク設定パケットの初期固定長部分は次のフィールドにより構成される。
・リンク設定フィールド
・1セットの応答確認及び関連フィールド(ack−set)
・サポートされる符号化方式のリスト
・ノードの公開キー
リンク設定パケットのリンク設定セクション
図6に示すリンク設定パケットの初期固定長部分は次のフィールドにより構成される。
ワークトークン(128):「ワークトークン」と題する節で記載されるワークトークン検証に使用されるランダム番号。ワークトークンによって、サービス拒否攻撃を防止し易くなる。ワークトークンは、ワークトークン有効期間によって決まる時間長に亘ってのみ有効であり、その後、新規のワークトークンを計算する必要がある。
TimeStamp(64):ワークトークンを計算した時刻(ustimeデータフォーマットを使用する)。このフィールドは、ハローインターバルごとではなく、ワークトークン有効期間ごとに更新される。
UNI(64):このCoCoノードを固有に特定するユニバーサルノード識別子(UNI)。このUNIは、未登録のUNIである。更に詳しい情報については[BLMS]を参照されたい。
HelloNum(32):このCoCoノードが送信するリンク設定パケットごとにインクリメントするシーケンス番号。リンク設定パケットは、ハローインターバルと呼ばれる一定の期間でブロードキャストされる。
NumAcks(16):このパケットに相乗りさせる確認応答の数。
NumEncodings(16):送信側CoCoノードがサポートする符号化方式の数。
NumEncodings(16):送信側CoCoノードがサポートする符号化方式の数。
リンク設定パケットの確認応答セクション
図7は、或る実施形態におけるリンク設定パケットの確認応答セクションを示すブロック図である。
図7は、或る実施形態におけるリンク設定パケットの確認応答セクションを示すブロック図である。
この一連のフィールドは、別のCoCoノードからのリンク設定パケットの受信の確認応答を含む。これらの確認応答をリンク設定パケットのリンク設定セクションに相乗りさせる。単一のリンク設定パケットに幾つかの確認応答を含めることができ、各確認応答によって、異なるCoCoノードからのリンク設定パケットの受信を確認応答する。一つのリンク設定パケットに含める確認応答の数は、リンク設定セクションのNumAcksフィールドによって与えられる(図6参照)。各確認応答は以下の一連のフィールドにより構成される。
Node Acked(64):確認応答の送信先のノードのユニバーサルノード識別子(UNI)。
HelloNum Last Heard(32):確認応答の送信先のノードから受信する最終パケットのHelloNum。
HelloNum Last Heard(32):確認応答の送信先のノードから受信する最終パケットのHelloNum。
Hold Time(32):確認応答の送信先のノードからの最終パケットの到着からの経過時間:図10を参照。
Ack Signature(64):このCoCoノードと、確認応答されるパケットのCoCoノードとの間で合意されたデフィー・ヘルマンキーのハッシュであり、このハッシュは、acksになりすます操作を防止するために使用される。使用されるハッシュ関数は、以下の「符号化方式及びセキュリティ」と題する節で説明される該当するノードペアによって合意される。
Ack Signature(64):このCoCoノードと、確認応答されるパケットのCoCoノードとの間で合意されたデフィー・ヘルマンキーのハッシュであり、このハッシュは、acksになりすます操作を防止するために使用される。使用されるハッシュ関数は、以下の「符号化方式及びセキュリティ」と題する節で説明される該当するノードペアによって合意される。
リンク設定パケットの符号化セクション
図8は、リンク設定パケットの符号化セクションを示すブロック図である。このセクションは一連の符号化方式フィールドを含み、一つの符号化方式フィールドが、送信元ノードがサポートする暗号化方式/ハッシュ化方式の各ペアに対応する。リンク設定パケットの符号化方式フィールドの数はリンク設定セクションのNumEncodingsフィールドによって与えられる(図6参照)。各符号化方式フィールドは以下のサブフィールドにより構成される:
Encryption(4):暗号化方式に対応する4ビット識別子であり、この暗号化方式は、暗号化方式に関連するハッシュ化方式と一緒に符号化方式ペアとして使用される。現在サポートされている暗号化方式はRC4,DES,3DES,Blowfish,及びAESである。
図8は、リンク設定パケットの符号化セクションを示すブロック図である。このセクションは一連の符号化方式フィールドを含み、一つの符号化方式フィールドが、送信元ノードがサポートする暗号化方式/ハッシュ化方式の各ペアに対応する。リンク設定パケットの符号化方式フィールドの数はリンク設定セクションのNumEncodingsフィールドによって与えられる(図6参照)。各符号化方式フィールドは以下のサブフィールドにより構成される:
Encryption(4):暗号化方式に対応する4ビット識別子であり、この暗号化方式は、暗号化方式に関連するハッシュ化方式と一緒に符号化方式ペアとして使用される。現在サポートされている暗号化方式はRC4,DES,3DES,Blowfish,及びAESである。
Hash(4):ハッシュ化方式に対応する4ビット識別子であり、このハッシュ化方式は、ハッシュ化方式に関連する符号化方式と一緒に符号化方式ペアとして使用される。現在サポートされているハッシュ化方式はMD5、SHA1,及びRIPEMDである。
Reserve(8):将来時点での使用のために確保される。
リンク設定パケットの公開キーセクション
図9は、リンク設定パケットの公開キーセクションを示すブロック図である。
リンク設定パケットの公開キーセクション
図9は、リンク設定パケットの公開キーセクションを示すブロック図である。
PublicKey Size(16):Public Keyフィールドのバイトサイズである。
Public Key(可変;普通、512):Diffle−Hellmanキー交換に使用される公開キー;「符号化方式及びセキュリティ」と題する節を参照。
Public Key(可変;普通、512):Diffle−Hellmanキー交換に使用される公開キー;「符号化方式及びセキュリティ」と題する節を参照。
往復時間及び受信品質の導出
図10は、往復時間及び受信品質を導出する方法を示すフロー図である。
リンク設定サブレイヤによって各ノードは、
・全ての他のノードに関するノード間往復時間
・他のノードからの信号の品質
・他のノードが検出する当該各ノード自体の信号の品質
の項目を導出することができる。
図10は、往復時間及び受信品質を導出する方法を示すフロー図である。
リンク設定サブレイヤによって各ノードは、
・全ての他のノードに関するノード間往復時間
・他のノードからの信号の品質
・他のノードが検出する当該各ノード自体の信号の品質
の項目を導出することができる。
ノードAがノードBとの間の往復時間を計算する場合、ノードAは、ノードAが設定パケットをノードBに送信する時刻と、ノードAがリンク設定パケットを、設定の確認応答を送信する(hello−numの値が同じであることをチェックする)ノードBから受信する時刻との間に経過した時間に注目し、次に該当する確認応答に生じるホールド時間を減算する。
往復時間の計算の他に、リンク設定レイヤは信号品質を、当該レイヤが送信するリンク設定パケットの内、後の時点で確認応答されるリンク設定パケットの割合に基づいて求めることができる。例えば、ノードBがノードAから、番号1,2,3,4,...が付されたハローパケットを受信する場合、ノードBは、ノードBが強い信号をノードAから受信していることを認識する。これとは異なり、ノードBがノードAから、番号4,9,15,23,...が付されたハローパケットを受信する場合、ノードBは、ノードAからの信号が相対的に弱いことを認識する。同様に、ノードAが確認応答をノードBから受信し、そしてノードAが受信するハローパケットのシーケンス番号の間隔が長くなってしまう(例えば、5,11,17,21,...)場合、ノードAは、ノードBからの信号が弱い、ノードAからノードBへの信号が弱い、または両方の信号ともに弱いことを認識する。
符号化方式及びセキュリティ
リンクレイヤの符号化方式及びセキュリティでは、ノード間のデフィー・ヘルマンキー交換だけでなく、ワークトークンの交換を利用して、サービス拒否攻撃を防止する。
リンクレイヤの符号化方式及びセキュリティでは、ノード間のデフィー・ヘルマンキー交換だけでなく、ワークトークンの交換を利用して、サービス拒否攻撃を防止する。
ワークトークン
不良ノードはサービス拒否攻撃をネットワークに対して次のようにして仕掛けることができる。
・不良ノードの通信範囲内のノードにリンク設定リクエストをフラッディングする。
・多数の偽ノードが存在するように見せかける。
不良ノードはサービス拒否攻撃をネットワークに対して次のようにして仕掛けることができる。
・不良ノードの通信範囲内のノードにリンク設定リクエストをフラッディングする。
・多数の偽ノードが存在するように見せかける。
これらのアクションは攻撃を構成する。なぜならば、リンク設定リクエストを受信するノードは、多くのリソースを消費する(400MHzで動作するXScaleプロセッサでは約1ミリ秒を消費する)デフィー・ヘルマンキー交換計算を実行する必要があるからである。多数の悪意のある設定リクエストが発信されている状況では、正当なノードからのリンク設定リクエストは全て、タイムアウトによって遅延する、または拒否される。
従って、リンク設定プロトコルは、ワークトークンと呼ばれる機構を使用して、リンクを設定しようとしているノードに、リソースを大量に消費する計算を強制的に実行させる。これにより、このようなサービス拒否攻撃が攻撃者にとってはコストが更に高く付くようになり、攻撃者の計算リソースによって変わるが、攻撃の確率を低くするか、または攻撃を全て防止する。
これらの事項が考慮されるので、ワークトークンの有効化がデフィー・へルマン計算の前に行なわれる。ワークトークンが無効化される場合、ノードは時間を、ワークトークンの検証よりもずっと高いコストを要する計算であるデフィー・へルマンキーの計算のために割く必要はない。
ノードAがリンク設定パケットをノードBに送信することができるようになる前に、ノードAは、ノードAがノードAのリンク設定パケットのワークトークンフィールドに格納する有効なワークトークンWを計算する必要がある(図6参照)。
タイムスタンプTもリンク設定パケットに含める(図6参照)。リンク設定パケットを受信すると、ノードBはタイムスタンプを使用してワークトークンの有効期間が満了になった(従って無効になる)かどうかを判断する。
ワークトークンアルゴリズム
以下のワークトークンアルゴリズムでは、関数hは、全てのCoCoノードが使用するプロトコルソースコード内に設定されるグローバルハッシュ関数である。関数hの出力は関数の範囲[0,MAX]に収まるように一様に分散させる。
以下のワークトークンアルゴリズムでは、関数hは、全てのCoCoノードが使用するプロトコルソースコード内に設定されるグローバルハッシュ関数である。関数hの出力は関数の範囲[0,MAX]に収まるように一様に分散させる。
以下のアルゴリズムのステップ3.bにおける値rは、MAXよりも小さくなるように選択される。この値rはネットワークプロビジョニングの時点で設定され、そして特に、このプロトコルのセキュリティと効率とのトレードオフを調整する手段として展開されるように選択することができる。このような操作を行なうのは、ステップ3.bがMAX/rの予測繰り返し数で確率論的に成功するからであり、成功するのは、関数hの出力が、関数の範囲に収まるように一様に分散しているからである。
以下のアルゴリズムにおいて使用される表記(Z,Y)は、Z及びYの2値表示の文字列連結を示す。
ワークトークン計算
ノードAは、ノードAが送出する全てのリンク設定パケットに有効なワークトークンが格納されていることを確認する必要がある。現在時刻と、ノードAが送信した最も直近のパケットのタイムスタンプとの時間差がワークトークン有効期間よりも短い場合、ノードAは最も直近のパケットを再送信する。時間差がワークトークン有効期間よりも短くはない場合、既に送信されているワークトークンはこの時点では無効であり、そしてワークトークンを、以下のステップを実行することにより再計算する必要がある。
1.ノードAはノードA自体を、ノードAのリンク設定パケットのUNIフィールド(図6参照)をノードAの名前Nに設定することにより確認する。
2.ノードAはリンク設定パケットのTimeStampフィールドを現在時刻Tに設定する、
3.ノードAは次に、
a.128ビットランダム番号Xを選択する。
ワークトークン計算
ノードAは、ノードAが送出する全てのリンク設定パケットに有効なワークトークンが格納されていることを確認する必要がある。現在時刻と、ノードAが送信した最も直近のパケットのタイムスタンプとの時間差がワークトークン有効期間よりも短い場合、ノードAは最も直近のパケットを再送信する。時間差がワークトークン有効期間よりも短くはない場合、既に送信されているワークトークンはこの時点では無効であり、そしてワークトークンを、以下のステップを実行することにより再計算する必要がある。
1.ノードAはノードA自体を、ノードAのリンク設定パケットのUNIフィールド(図6参照)をノードAの名前Nに設定することにより確認する。
2.ノードAはリンク設定パケットのTimeStampフィールドを現在時刻Tに設定する、
3.ノードAは次に、
a.128ビットランダム番号Xを選択する。
b.テストしてc=h(X,T,N,X)<r.(コンマは連結演算を表わす)であるかどうかを調査する。
c.ステップ3.a及び3.bを、結果として得られるcが実際にrよりも小さくなるようなXをノードAが見付け出すまで繰り返す。
4.ノードAはノードAのリンク設定パケットのワークトークンフィールドをワークトークンWに設定し、ワークトークンWは、ステップ3.cを完了させるために使用されたXの成功値である。
c.ステップ3.a及び3.bを、結果として得られるcが実際にrよりも小さくなるようなXをノードAが見付け出すまで繰り返す。
4.ノードAはノードAのリンク設定パケットのワークトークンフィールドをワークトークンWに設定し、ワークトークンWは、ステップ3.cを完了させるために使用されたXの成功値である。
新規の有効なワークトークンがこの時点で計算されると、ノードAは、W,T,及びNの値を、パケットのリンク設定セクションの適切なフィールドに格納するリンク設定パケットを送出する。
1.1.1.1.1 ワークトークン検証
ノードBがリンク設定パケットをノードAから受信すると、ノードBは、ノードAへのリンク設定を継続する前にワークトークンが有効であることを検証する必要がある。ワークトークンの検証は、デフィー・へルマンキーの計算よりもずっと速く行なわれるのでオーバーヘッドが小さくなる。なぜならば、リンク設定パケットの全てが有効なワークトークンを含む訳ではなく、かつリソースがこれらのパケットのデフィー・へルマンキーの計算に消費されることがないからである。更に、無効なワークトークンを含む全てのリンク設定パケットを、更に処理することなく無視することにより、プロトコルは、当該プロトコルが使用するパケットの数を減らし、従ってプロトコルによって発生するトラフィックオーバーヘッド全体も小さくなる。障害を更に処理することなく無視することにより、攻撃に対する露出を減らすこともできる。なぜならば、プロトコルによるアクティビティが少なくなると、アクティビティを利用する機会が少なくなるからである。
ノードBがリンク設定パケットをノードAから受信すると、ノードBは、ノードAへのリンク設定を継続する前にワークトークンが有効であることを検証する必要がある。ワークトークンの検証は、デフィー・へルマンキーの計算よりもずっと速く行なわれるのでオーバーヘッドが小さくなる。なぜならば、リンク設定パケットの全てが有効なワークトークンを含む訳ではなく、かつリソースがこれらのパケットのデフィー・へルマンキーの計算に消費されることがないからである。更に、無効なワークトークンを含む全てのリンク設定パケットを、更に処理することなく無視することにより、プロトコルは、当該プロトコルが使用するパケットの数を減らし、従ってプロトコルによって発生するトラフィックオーバーヘッド全体も小さくなる。障害を更に処理することなく無視することにより、攻撃に対する露出を減らすこともできる。なぜならば、プロトコルによるアクティビティが少なくなると、アクティビティを利用する機会が少なくなるからである。
各ノードBは、ノードBが有効なリンク設定リクエストを受信した受信先の各ノードAに関して前に計算したデフィー・へルマンキーのキャッシュを維持する。これにより、ノードBは確実に、ノードAに対するノードBによる確認応答が紛失する場合に、デフィー・へルマンキーを再計算しなくても済むようになる。キャッシュされたキーを使用して、直近に廃棄されたリンクを迅速に再設定することもできる。ノードBは最終的に、ノードAに関してノードBでキャッシュされたキーを、ノードBがリンク設定パケットをノードAから、デフィー・へルマンキャッシュインターバルよりも長い期間に亘って受信することがない場合に破棄する。
ノードAからのリンク設定パケットに含まれるワークトークンが有効であることを検証するために、ノードBは以下の項目を実行する:
1.ノードBはW,T,及びNを、ノードBがノードAから受信したリンク設定パケットのワークトークンフィールド,タイムスタンプフィールド,及びUNIフィールドからそれぞれ抽出する;図6参照。
2.ノードBは、ワークトークンの有効期間が満了になったかどうかについて、リンク設定パケットのタイムスタンプT、現在時刻、及びワークトークン有効期間に基づいてチェックする。
1.ノードBはW,T,及びNを、ノードBがノードAから受信したリンク設定パケットのワークトークンフィールド,タイムスタンプフィールド,及びUNIフィールドからそれぞれ抽出する;図6参照。
2.ノードBは、ワークトークンの有効期間が満了になったかどうかについて、リンク設定パケットのタイムスタンプT、現在時刻、及びワークトークン有効期間に基づいてチェックする。
a.ワークトークンの有効期間が満了になった場合、ノードBはリンク設定リクエストを、ノードAがパケットフラッド攻撃またはリプライ攻撃を、W及びTの前の有効値を使用することにより試みる可能性があるので無視する。
b.ワークトークンの有効期間が満了になっていない場合、ノードBは検証プロセスを継続する。
3.ノードBは、ノードAからのキャッシュされたデフィー・へルマンキーを有しているかどうかについてチェックする。
3.ノードBは、ノードAからのキャッシュされたデフィー・へルマンキーを有しているかどうかについてチェックする。
a.ノードAに対応するキャッシュされたキーが存在する場合、ノードBはノードAに、ノードBが送出する次のリンク設定パケットで確認応答を返し、Ack署名フィールド(図7参照)を、ノードBのキャッシュのハッシュキーに設定する。
b.ノードAに対応するキャッシュされたキーが存在しない場合、ノードBは検証プロセスを継続する。
4.ノードBはv=h(W,T,N,W)を計算する(コンマは連結演算を表わす)。vの値は、ワークトークン計算(前に説明した)のステップ3.bにおいて計算されたcの成功値と同じとなる必要があるので、vはrよりも小さくなければならない。
4.ノードBはv=h(W,T,N,W)を計算する(コンマは連結演算を表わす)。vの値は、ワークトークン計算(前に説明した)のステップ3.bにおいて計算されたcの成功値と同じとなる必要があるので、vはrよりも小さくなければならない。
a.v≧rの場合、ノードBはリンク設定リクエストを、ノードAが有効なワークトークンを送信しておらず、従って不良ノードである可能性があるので無視する。
b.v<rの場合、ノードAが有効なワークトークンを送信しているので、ノードBはリンク設定プロセスを継続する。
b.v<rの場合、ノードAが有効なワークトークンを送信しているので、ノードBはリンク設定プロセスを継続する。
有効なワークトークンが検証されると、ノードBは、ノードBがノードAから受信したリンク設定パケットに対して確認応答を返すことによりリンク設定プロセスを継続する状態になる。
リンク設定リクエストに対する確認応答
ノードAが有効なワークトークンを送信したことを検証した後、ノードBはリンク設定を継続する。ノードBが、ノードAとの間のノードBのリンクに関するデフィー・へルマンキーのキャッシュ値を既に有しているということがない場合(ワークトークン検証アルゴリズムのステップ3を参照)、ノードBは以下のステップを実行する。
1.ノードBは、ノードAとの間のノードBのリンクに関するデフィー・へルマンキーを計算する。更なる情報に関しては、「デフィー・へルマンキー交換」と題する節を参照されたい。
2.ノードBはデフィー・へルマンキーを、ノードAを識別するUNIに関連付けてキャッシュする。ノードAは定期的に、ノードAのリンク設定ハローパケットをブロードキャストし、そしてノードBは、ノードBがノードAから受信する各ハローに対して確認応答を返すので、デフィー・へルマンキーのキャッシュバージョンを維持することが有用となる。
3.ノードBは、暗号化関数/ハッシュ化関数ペアをリンクに関して作成する。更なる情報に関しては、「設定リンクの暗号化及びハッシュ化」と題する節を参照されたい。
4.ノードBはノードAに対して、ノードBがブロードキャストする次のリンク設定パケットで確認応答を返して、Ack署名フィールド(図7参照)を、ノードBが計算したハッシュ化デフィー・へルマンキーに設定する。これにより、ノードAは確認応答の認証を迅速に行なうことができ、これにより、不良ノードが、なりすましたAckを送信する現象を防止することができ、なりすました応答は、未使用リンクを開放されたままの状態とし、そして性能を悪化させるように作用する、というのは、不要な確認応答の全てをノードAが、ノードAのリンク設定パケットに含める必要があることになるからである。
ノードAが有効なワークトークンを送信したことを検証した後、ノードBはリンク設定を継続する。ノードBが、ノードAとの間のノードBのリンクに関するデフィー・へルマンキーのキャッシュ値を既に有しているということがない場合(ワークトークン検証アルゴリズムのステップ3を参照)、ノードBは以下のステップを実行する。
1.ノードBは、ノードAとの間のノードBのリンクに関するデフィー・へルマンキーを計算する。更なる情報に関しては、「デフィー・へルマンキー交換」と題する節を参照されたい。
2.ノードBはデフィー・へルマンキーを、ノードAを識別するUNIに関連付けてキャッシュする。ノードAは定期的に、ノードAのリンク設定ハローパケットをブロードキャストし、そしてノードBは、ノードBがノードAから受信する各ハローに対して確認応答を返すので、デフィー・へルマンキーのキャッシュバージョンを維持することが有用となる。
3.ノードBは、暗号化関数/ハッシュ化関数ペアをリンクに関して作成する。更なる情報に関しては、「設定リンクの暗号化及びハッシュ化」と題する節を参照されたい。
4.ノードBはノードAに対して、ノードBがブロードキャストする次のリンク設定パケットで確認応答を返して、Ack署名フィールド(図7参照)を、ノードBが計算したハッシュ化デフィー・へルマンキーに設定する。これにより、ノードAは確認応答の認証を迅速に行なうことができ、これにより、不良ノードが、なりすましたAckを送信する現象を防止することができ、なりすました応答は、未使用リンクを開放されたままの状態とし、そして性能を悪化させるように作用する、というのは、不要な確認応答の全てをノードAが、ノードAのリンク設定パケットに含める必要があることになるからである。
デフィー・へルマンキー交換
デフィー・へルマンキー交換は、リンクレイヤのセキュリティ及び符号化のための一つの構成要素であるので、この節では、プロセスを簡単に概括する。
デフィー・へルマンキー交換は、リンクレイヤのセキュリティ及び符号化のための一つの構成要素であるので、この節では、プロセスを簡単に概括する。
ノードA及びBは素数p、及びpを法とする原始元gを共有する(値p及びgは各デバイスにプロビジョニング時に供給され、そして公開することができる)。ノードAは秘密キーαを選択する。ノードBは秘密キーβを選択する(α及びβはそれぞれ1〜p−1の範囲の値である)。CoCoノードには秘密キーをプロビジョニング時に供給することができる、またはCoCoノードは秘密キーをスタートアップ時に、幾つかの標準的な方法のいずれかによって選択することができる([S]の「キーの生成」と題する節を参照)。2つのノードの間で交換されるキーは以下のようにして計算される。
1.ノードAはノードBに、ノードAの公開キーを送信する−値PA=gα(ノードAからノードBへのリンク設定ハローパケットで公開キーフィールドに格納して送信される;図9参照)
2.ノードBはノードAに、ノードBの公開キーを送信する−値PB=gβ(ノードBからノードAへのリンク設定ハローパケットに乗せ、公開キーフィールドに格納して送信される;図9参照)
3.ノードAは、(PB)α=(gβ)αを計算する。
4.ノードBは、(PA)β=(gα)βを計算する。
5.ステップ3及び4から得られるこれらの2つの値は同じであるので、この同じ値はkDH(AB)と表記することができる、または前後関係が理解できる場合には単にkと表記することができる。この値はノードA及びBの両方に認識され、かつ他のどのノードにも認識されることがない。なぜならば、αをgαから導出する操作は計算上、実行不可能である([S]を参照)。従って、ノードA及びBはαを、ノードAとBとの間のリンクで送信される全てのデータに関してこれらのノードが使用することになる暗号化方法の秘密キーとして使用することができる(「設定リンクの暗号化及びハッシュ化」と題する節を参照されたい)。
1.ノードAはノードBに、ノードAの公開キーを送信する−値PA=gα(ノードAからノードBへのリンク設定ハローパケットで公開キーフィールドに格納して送信される;図9参照)
2.ノードBはノードAに、ノードBの公開キーを送信する−値PB=gβ(ノードBからノードAへのリンク設定ハローパケットに乗せ、公開キーフィールドに格納して送信される;図9参照)
3.ノードAは、(PB)α=(gβ)αを計算する。
4.ノードBは、(PA)β=(gα)βを計算する。
5.ステップ3及び4から得られるこれらの2つの値は同じであるので、この同じ値はkDH(AB)と表記することができる、または前後関係が理解できる場合には単にkと表記することができる。この値はノードA及びBの両方に認識され、かつ他のどのノードにも認識されることがない。なぜならば、αをgαから導出する操作は計算上、実行不可能である([S]を参照)。従って、ノードA及びBはαを、ノードAとBとの間のリンクで送信される全てのデータに関してこれらのノードが使用することになる暗号化方法の秘密キーとして使用することができる(「設定リンクの暗号化及びハッシュ化」と題する節を参照されたい)。
デフィー・へルマンキー交換後の識別情報の継続性
リンク設定パケット及びデフィー・へルマンキーをノードAとBとの間で交換した後、各ノードは、他方のノードが有効な秘密キーを持っていたはずであることを認識する。次に、キーKDH(AB)が、このリンクが使用されるセッション全体を通じて使用されるので、一旦セッションが始まると介入者攻撃が行なわれることがない。いずれの介入者攻撃も、リンク設定の前に仕掛けられているはずであり、リンクの寿命の間は継続して行なわれるはずである。デフィー・へルマンキー交換によって、識別情報の継続性が保証される;すなわち、一旦、或るノードが通信を或るリンクで開始すると、同じノードとの通信が、リンクセッションの期間の間は保証される。
リンク設定パケット及びデフィー・へルマンキーをノードAとBとの間で交換した後、各ノードは、他方のノードが有効な秘密キーを持っていたはずであることを認識する。次に、キーKDH(AB)が、このリンクが使用されるセッション全体を通じて使用されるので、一旦セッションが始まると介入者攻撃が行なわれることがない。いずれの介入者攻撃も、リンク設定の前に仕掛けられているはずであり、リンクの寿命の間は継続して行なわれるはずである。デフィー・へルマンキー交換によって、識別情報の継続性が保証される;すなわち、一旦、或るノードが通信を或るリンクで開始すると、同じノードとの通信が、リンクセッションの期間の間は保証される。
設定リンクの暗号化及びハッシュ化
各ノードは、当該ノードがサポートする符号化方式の番号付きリストを維持する。リスト中の各符号化方式は、ハッシュ化関数とペアリングされる暗号化方式を表わす。或るノードがリンク設定パケットを送信する場合、当該ノードは、このリストに現われる符号化方式をパケットの符号化セクションに格納する(図5及び図8を参照)。符号化方式はリンク設定パケットに、これらの符号化方式が当該ノードの番号付きリストに現われる順番と同じ順番で現われる。
各ノードは、当該ノードがサポートする符号化方式の番号付きリストを維持する。リスト中の各符号化方式は、ハッシュ化関数とペアリングされる暗号化方式を表わす。或るノードがリンク設定パケットを送信する場合、当該ノードは、このリストに現われる符号化方式をパケットの符号化セクションに格納する(図5及び図8を参照)。符号化方式はリンク設定パケットに、これらの符号化方式が当該ノードの番号付きリストに現われる順番と同じ順番で現われる。
ノードAがリンク設定(ハロー)パケットをノードBに送信し、そしてノードBがリンク設定確認応答パケットをノードAに送信した後、ノードA及びBはそれぞれ、ペアリングされ、他方のノードがサポートし、そしてノードの意思に従って順番付けされた暗号化方式及びハッシュ関数のリストを有する。ノードA及びBはそれぞれ、以下のステップを実行して、これらの符号化方式の内のいずれの符号化方式を新規に設定されたA−Bリンクで使用すべきかについて判断する。
1.ノードAまたはノードBのいずれの符号化器が優先されるかを判断する(以下の節を参照)。
2.優先される符号化器のリストの中で最も優先度が高く、かつ他のノードのリストにも現われる符号化方式を選択する。一致する符号化方式が見つからない場合、通信が、暗号化されていないこのリンクで行なわれる。(セキュリティ要件によって、データを暗号化されていないリンクで送信してはならない場合、データ送信に使用される回線に、暗号化されていないリンクを決して含めてはならない;更なる情報については[BMV]を参照されたい)。
1.ノードAまたはノードBのいずれの符号化器が優先されるかを判断する(以下の節を参照)。
2.優先される符号化器のリストの中で最も優先度が高く、かつ他のノードのリストにも現われる符号化方式を選択する。一致する符号化方式が見つからない場合、通信が、暗号化されていないこのリンクで行なわれる。(セキュリティ要件によって、データを暗号化されていないリンクで送信してはならない場合、データ送信に使用される回線に、暗号化されていないリンクを決して含めてはならない;更なる情報については[BMV]を参照されたい)。
このリンク符号化方式選択アルゴリズムでは、各参加ノードが単一のパケットのみを受信することが要求されるので、このアルゴリズムは非常に効率的である。
優先される符号化器を決定するアルゴリズム
このアルゴリズムは決定論的プロセスであり、このプロセスによって、ノードA及びBの両方が結果について合意することにより結論を出す。ノードA及びBはこのアルゴリズムを、(PA−PB)をpで割ったときの余り、及び(PB−PA)をpで割ったときの余りを比較することにより実行する。前者の方が大きい場合、ノードAの符号化器が優先され;後者の方が大きい場合、ノードBの符号化器が優先される。この場合、PA及びPBは、それぞれノードA及びBのデフィー・へルマン公開キーであり、そしてpは法となる素数であり、この素数を使用してデフィー・へルマン計算を行なう。このアルゴリズムは決定論的であるので、ノードA及びBの両方が、優先される同じ符号化器を計算により求めることに注目されたい。
優先される符号化器を決定するアルゴリズム
このアルゴリズムは決定論的プロセスであり、このプロセスによって、ノードA及びBの両方が結果について合意することにより結論を出す。ノードA及びBはこのアルゴリズムを、(PA−PB)をpで割ったときの余り、及び(PB−PA)をpで割ったときの余りを比較することにより実行する。前者の方が大きい場合、ノードAの符号化器が優先され;後者の方が大きい場合、ノードBの符号化器が優先される。この場合、PA及びPBは、それぞれノードA及びBのデフィー・へルマン公開キーであり、そしてpは法となる素数であり、この素数を使用してデフィー・へルマン計算を行なう。このアルゴリズムは決定論的であるので、ノードA及びBの両方が、優先される同じ符号化器を計算により求めることに注目されたい。
リンクステート
図11は利用可能なリンクステートを示すステート図である。
それぞれのノードがリンクステートテーブルを保持し、リンクステートテーブルは、それぞれのノードが受信を行なった受信先の各ノードに対応するエントリを含み、エントリは次の項目を含む:
・当該ノードと通信するために使用されるデフィー・へルマンキー(「符号化方式及びセキュリティ」と題する節を参照)。
・それぞれのノードが当該ノードから受信した最後のhello−num。
・それぞれのノードが当該ノードから受信した最後の確認応答に含まれるhello−num。
図11は利用可能なリンクステートを示すステート図である。
それぞれのノードがリンクステートテーブルを保持し、リンクステートテーブルは、それぞれのノードが受信を行なった受信先の各ノードに対応するエントリを含み、エントリは次の項目を含む:
・当該ノードと通信するために使用されるデフィー・へルマンキー(「符号化方式及びセキュリティ」と題する節を参照)。
・それぞれのノードが当該ノードから受信した最後のhello−num。
・それぞれのノードが当該ノードから受信した最後の確認応答に含まれるhello−num。
それぞれのノードは、それぞれのノードが受信した受信先の各ノードに関してステートマシンを維持する。ノードAのステートマシンは、ノードBとの間のノードAのリンクのステートを管理し、そしてA−Bリンクステートマシンと呼ばれる。ノードAのA−Bリンクステートマシンは、4つのステートの内の一つのステートになることができる(図11参照):
・Blank:ノードAはノードBに気付いていない。
・0−way:ノードAはノードBに気付いているが、リンク設定ハローをノードBから受信していない(ノードAはノードBを認識するが、ノードAはノードBからの受信を行なっていない)。
・1−way:ノードAはリンク設定ハローをノードBから受信しているが、確認応答をノードBから受信していない(ノードAはノードBからの受信を行なっているが、ノードAは、ノードBがノードAからの受信を行なっているかどうかを認識していない)。
・2−way:ノードAはリンク設定ハローをノードBから受信しており、更に確認応答をノードBから受信している(ノードAはノードBからの受信を行ない、そしてノードAは、ノードBもノードAからの受信を行なっていることを認識している)。
・Blank:ノードAはノードBに気付いていない。
・0−way:ノードAはノードBに気付いているが、リンク設定ハローをノードBから受信していない(ノードAはノードBを認識するが、ノードAはノードBからの受信を行なっていない)。
・1−way:ノードAはリンク設定ハローをノードBから受信しているが、確認応答をノードBから受信していない(ノードAはノードBからの受信を行なっているが、ノードAは、ノードBがノードAからの受信を行なっているかどうかを認識していない)。
・2−way:ノードAはリンク設定ハローをノードBから受信しており、更に確認応答をノードBから受信している(ノードAはノードBからの受信を行ない、そしてノードAは、ノードBもノードAからの受信を行なっていることを認識している)。
ノードAはリンク設定データパケットをノードBに、A−Bリンクステートマシンがステート2−wayになっているときにのみ送信する。
MをノードAのA−Bリンクステートマシンとする。ステートマシンMは、以下の6つの態様の内の一つの態様で遷移することができる。
1.Mがステートblankまたは0−wayであり、かつノードAがリンク設定ハローパケットをノードBから受信する場合、次のようになる。
・Mは、
・ステート1−way:ノードBからのリンク設定パケットがノードAに対する確認応答を含まない場合、
・ステート2−way:ノードBからのリンク設定パケットが更に、ノードAに対する確認応答を含む場合(この状態は、例えばノードAがノードBとの間のリンク設定を開始した場合に生じる)、
のステートの内の一つのステートに移行する。
・ノードA:
・ワークトークンを有効にする、
・暗号化/ハッシュ化関数ペアをリンクに関して作成する、
・デフィー・へルマンキーを計算し、そしてキャッシュする(キーが既にキャッシュされていることがない場合)、
・ノードBを、ノードBの確認応答リストに追加する、
2.Mがステート1−wayであり、かつノードAがノードA自体に関するリンク設定確認応答をノードBから受信する場合、次のようになる。
・Mはステート2−wayに移行する。
3.Mがステート2−wayであり、かつノードAがノードA自体に関するリンク設定確認応答をノードBから、確認応答インターバルよりも長い期間に亘って受信しない場合、次のようになる。
・Mはステート1−wayに移行する。
4.Mがステート1−wayまたは2−wayであり、かつノードAがリンク設定ハローをノードBから、確認応答インターバルよりも長い期間に亘って受信しない場合、次のようになる。
・Mはステート0−wayに移行する。
・ノードAはノードBを、ノードAの確認応答リストから削除する。
5.Mがステート0−wayであり、かつノードAのデフィー・へルマンキャッシュインターバルが満了すると、次のようになる。
・Mはステートblankに移行する。
・ノードAはノードBに対応するデフィー・へルマンキーをノードAのキャッシュから削除する。
6.全てのステートにおいて、ノードAはハローインターバルごとに、(増分された)hello−num、タイムスタンプ、及びワークトークンを含むリンク設定パケットと、そして最後の確認応答インターバルにノードAが受信を行なった受信先の各ノードに対する確認応答と、を送信する(確認応答はノードAのリンクステートテーブルにエントリを有する)。
MをノードAのA−Bリンクステートマシンとする。ステートマシンMは、以下の6つの態様の内の一つの態様で遷移することができる。
1.Mがステートblankまたは0−wayであり、かつノードAがリンク設定ハローパケットをノードBから受信する場合、次のようになる。
・Mは、
・ステート1−way:ノードBからのリンク設定パケットがノードAに対する確認応答を含まない場合、
・ステート2−way:ノードBからのリンク設定パケットが更に、ノードAに対する確認応答を含む場合(この状態は、例えばノードAがノードBとの間のリンク設定を開始した場合に生じる)、
のステートの内の一つのステートに移行する。
・ノードA:
・ワークトークンを有効にする、
・暗号化/ハッシュ化関数ペアをリンクに関して作成する、
・デフィー・へルマンキーを計算し、そしてキャッシュする(キーが既にキャッシュされていることがない場合)、
・ノードBを、ノードBの確認応答リストに追加する、
2.Mがステート1−wayであり、かつノードAがノードA自体に関するリンク設定確認応答をノードBから受信する場合、次のようになる。
・Mはステート2−wayに移行する。
3.Mがステート2−wayであり、かつノードAがノードA自体に関するリンク設定確認応答をノードBから、確認応答インターバルよりも長い期間に亘って受信しない場合、次のようになる。
・Mはステート1−wayに移行する。
4.Mがステート1−wayまたは2−wayであり、かつノードAがリンク設定ハローをノードBから、確認応答インターバルよりも長い期間に亘って受信しない場合、次のようになる。
・Mはステート0−wayに移行する。
・ノードAはノードBを、ノードAの確認応答リストから削除する。
5.Mがステート0−wayであり、かつノードAのデフィー・へルマンキャッシュインターバルが満了すると、次のようになる。
・Mはステートblankに移行する。
・ノードAはノードBに対応するデフィー・へルマンキーをノードAのキャッシュから削除する。
6.全てのステートにおいて、ノードAはハローインターバルごとに、(増分された)hello−num、タイムスタンプ、及びワークトークンを含むリンク設定パケットと、そして最後の確認応答インターバルにノードAが受信を行なった受信先の各ノードに対する確認応答と、を送信する(確認応答はノードAのリンクステートテーブルにエントリを有する)。
リンクデータサブレイヤ
リンクデータサブレイヤは、データをノードから次々に設定リンクを経由して取得し、データフローを管理し、遅延及び往復時間のようなQoS測定値をモニタリングし、そして圧縮及びフラグメンテーションを実行する役割を担う。
リンクデータサブレイヤは、データをノードから次々に設定リンクを経由して取得し、データフローを管理し、遅延及び往復時間のようなQoS測定値をモニタリングし、そして圧縮及びフラグメンテーションを実行する役割を担う。
上位レイヤのパケットタイプ
リンク設定パケットではないパケットは必ずリンクレイヤで、上位プロトコルレイヤ宛てのデータとして処理され、CoCoプロトコルでは、これらの上位プロトコルレイヤは、ルーティングレイヤ、回線レイヤ、及びネーミングシステムレイヤを含む。
・クラスタリングパケットは、クラスター、多くの効率的なルーティングを可能にするCoCoノードへの再帰的分解に関連する情報を含む([BLMS]を参照)。
・広告パケットは、ノードに到達するためのコストに関する情報を含む([BLMS]を参照)。
・回線制御パケットは、専用のエンドツーエンド通信経路である回線の設定及び維持に関する情報を含む([BMV]を参照)。
リンク設定パケットではないパケットは必ずリンクレイヤで、上位プロトコルレイヤ宛てのデータとして処理され、CoCoプロトコルでは、これらの上位プロトコルレイヤは、ルーティングレイヤ、回線レイヤ、及びネーミングシステムレイヤを含む。
・クラスタリングパケットは、クラスター、多くの効率的なルーティングを可能にするCoCoノードへの再帰的分解に関連する情報を含む([BLMS]を参照)。
・広告パケットは、ノードに到達するためのコストに関する情報を含む([BLMS]を参照)。
・回線制御パケットは、専用のエンドツーエンド通信経路である回線の設定及び維持に関する情報を含む([BMV]を参照)。
リンクデータパケット
リンク設定パケットとは異なり、リンクデータパケットはユーザデータを含む。データの長さは、パケットヘッダ中では規定されない。なぜならば、全てのパケット長は、プロトコル抽象化レイヤで作られたCoCoヘッダに含まれるからである(図4参照)。各データパケットのCoCoヘッダはノードのメモリに格納されるので、当該ヘッダには、パケットデータを使用することになる上位レベルプロトコルが容易にアクセスすることができる。
リンク設定パケットとは異なり、リンクデータパケットはユーザデータを含む。データの長さは、パケットヘッダ中では規定されない。なぜならば、全てのパケット長は、プロトコル抽象化レイヤで作られたCoCoヘッダに含まれるからである(図4参照)。各データパケットのCoCoヘッダはノードのメモリに格納されるので、当該ヘッダには、パケットデータを使用することになる上位レベルプロトコルが容易にアクセスすることができる。
データパケットをノードの間で送信することができる前に、リンクをノードAとノードBとの間に設定する必要がある。従って、ノードA及びBはリンク設定パケットを授受し、そしてこれらのノードのリンクに固有のデフィー・へルマンキーkDH(AB)を計算することになる(「デフィー・へルマンキー交換」と題する節を参照)。ノードA及びBは更に、A−Bリンクに固有のハッシュ関数hAB、及び暗号化方式eABについて合意することになる(「設定リンクの暗号化及びハッシュ化」を参照)。
データパケットコンテンツ全体が関数eABで暗号化される。“none”が暗号化方式の内の一つの暗号化方式であるので、ノードA及びBが共に“none”を暗号化方式として合意した場合、ノードA及びBの各ノードは、送信時に暗号化を試みず、かつ受信時に解読を試みないことを認識する。
リンクデータパケット−セクションによって分離され−図12に示され、破線は繰り返すことができるパケットのセクションを示し、そして括弧内の数字はフィールドサイズをビット単位で示している。
リンクデータパケットは以下のセクションを含む。
・データパケットをマルチキャストするときに使用されるフィールド
・データパケットのセキュアチェックサムとして利用される署名
・各データパケットに固有の情報
・パケットをフラグメント化する必要がある場合にデータを再構成することができるようなフラグメンテーション情報
・受信したデータパケットに対する一連の確認応答
・確認応答されるパケットの平均ホールド時間
・上位プロトコルレイヤで処理されることになる、またはネットワークインターフェースレイヤに送信されることになる実際のデータ。
・データパケットをマルチキャストするときに使用されるフィールド
・データパケットのセキュアチェックサムとして利用される署名
・各データパケットに固有の情報
・パケットをフラグメント化する必要がある場合にデータを再構成することができるようなフラグメンテーション情報
・受信したデータパケットに対する一連の確認応答
・確認応答されるパケットの平均ホールド時間
・上位プロトコルレイヤで処理されることになる、またはネットワークインターフェースレイヤに送信されることになる実際のデータ。
リンクデータパケットのマルチキャストセクション
図13は、マルチキャスト処理を示すブロック図である。リンクレイヤプロトコルはマルチキャストをサポートする。マルチキャストをサポートすることによって、単一の送信元から複数の送信先に送信されるデータの送信を冗長にならないように行なうことができ、これは、送信元から送信先に達するリンクがインターフェースを共有する場合に、データパケットのコピーが一つだけ、ブロードキャストインターフェースを経由して送信されることを意味する。例えば、ノードAが図13に示すように、ノードB及びCに達するリンクを同じ無線インターフェースを使用して持っていると仮定する。同じパケットをノードB及びCの両方に送信するために、ノードAはパケットを、インターフェースを経由して1回だけブロードキャストする。
図13は、マルチキャスト処理を示すブロック図である。リンクレイヤプロトコルはマルチキャストをサポートする。マルチキャストをサポートすることによって、単一の送信元から複数の送信先に送信されるデータの送信を冗長にならないように行なうことができ、これは、送信元から送信先に達するリンクがインターフェースを共有する場合に、データパケットのコピーが一つだけ、ブロードキャストインターフェースを経由して送信されることを意味する。例えば、ノードAが図13に示すように、ノードB及びCに達するリンクを同じ無線インターフェースを使用して持っていると仮定する。同じパケットをノードB及びCの両方に送信するために、ノードAはパケットを、インターフェースを経由して1回だけブロードキャストする。
多くの受信側が同じブロードキャストリンクを共有する状態でメッセージをマルチキャストする場合、マルチキャストをサポートすることは、帯域利用率が大幅に低下することを意味する。しかしながら、マルチキャストの受信側は異なるデフィー・へルマンキーを使用して、送信元ノードに達する受信側のリンク上でデータを暗号化するので、マルチキャストデータパケットは暗号化されない。図14は、リンクデータパケットのマルチキャストセクションを示している;このセクションはユニキャストデータパケットには設けられない。
送信先セットを使用してマルチキャスト効率を高める
図14は、リンクデータパケットの送信先セットセクションを示すブロック図である。マルチキャストパケットを送信する前に、或るノードは、どのノードがブロードキャストデータの所望の受信側であるかを特定する必要がある。所望の各受信側に関して、当該或るノードは署名を計算し、そして発信パケットに追加する(「リンクデータパケットの署名セクション」を参照)。更に、ブロードキャスト送信ノードは、24ビットのハッシュ値を所望の受信側のUNIの連結に基づいて生成する。このハッシュ値をリンクデータパケットのDestSetHashフィールドに織り込む(図14参照)。DestSetHash値は、ブロードキャストパケットを受信するノード群が、これらのノードが所望の受信側の内のいずれかの受信側であるかどうかを判断するための迅速な手段となる。
図14は、リンクデータパケットの送信先セットセクションを示すブロック図である。マルチキャストパケットを送信する前に、或るノードは、どのノードがブロードキャストデータの所望の受信側であるかを特定する必要がある。所望の各受信側に関して、当該或るノードは署名を計算し、そして発信パケットに追加する(「リンクデータパケットの署名セクション」を参照)。更に、ブロードキャスト送信ノードは、24ビットのハッシュ値を所望の受信側のUNIの連結に基づいて生成する。このハッシュ値をリンクデータパケットのDestSetHashフィールドに織り込む(図14参照)。DestSetHash値は、ブロードキャストパケットを受信するノード群が、これらのノードが所望の受信側の内のいずれかの受信側であるかどうかを判断するための迅速な手段となる。
或るノードがブロードキャストパケットを受信すると、当該ノードは、受信パケットのDestSetHashフィールドを、既に受信しているDestSetHash値のテーブルと比較する。テーブルでは、DestSetHashを、パケットに格納されて送信される一連の署名の中の当該ノードの署名の位置と相互参照する。ノードが所望の受信側ではない場合、署名位置は当該DestSetHash値に関して0となり、そしてノードはパケットを廃棄することができる。
受信パケットのDestSetHashフィールドがテーブルに含まれない場合、ノードは、当該ノードの署名をパケットに関して計算し(「リンクデータパケットの署名セクション」を参照)、そして当該ノードの署名を、パケットに付加される複数の署名(これらの署名は所望の受信側を示す)の各署名と比較する。ノードが一致することを確認する場合、当該ノードはDestSetHash値及び署名位置を既知のDestSetHash値から成る当該ノードのテーブルに加える。署名の一致が確認されない場合、DestSetHash値をテーブルに、署名位置を0とすることにより加え、当該ノードが、このDestSetHashを格納するブロードキャストパケットの所望の受信側の内の一つの受信側ではないことを表示する。次に、ノードは当該パケットを廃棄する。
署名はパケット完全性のチェックサムとしても機能するので、不完全なデータを含むパケットは、データが完全な場合の該当する同じパケットとは異なる署名を有することになる。このような不完全なパケットが、所望の受信側に新規のDestSetHash値を含む形で到着した場合、所望の受信側は一致する署名を全く確認することができないので、このDestSetHash値が、このノード(パケットを受信したノード)が所望の受信ノードではないことを示していると間違って結論付けることになる。従って、このノードは、このDestSetHash値を有し、かつこの時点以降に到着する全てのブロードキャストパケットを間違って無視してしまう。この現象は、ネットワークインターフェースレベルの一部であるメディアアクセスコントロール(MAC)レベルで行なわれるチェックサムを利用して、パケットの完全性を確保することにより回避することができる。
リンクデータパケットのマルチキャストセクションに含まれるフィールド
NumSigs(8):パケットに組み込まれる署名の数。この数は、1〜255の範囲である。個別の署名は、マルチキャストデータパケットの所望の各受信側に関して生成される(「リンクデータパケットの署名セクション」を参照)。このフィールドはマルチキャストデータパケットにのみ含まれる。当該フィールドはユニキャストデータパケットには含まれない。
NumSigs(8):パケットに組み込まれる署名の数。この数は、1〜255の範囲である。個別の署名は、マルチキャストデータパケットの所望の各受信側に関して生成される(「リンクデータパケットの署名セクション」を参照)。このフィールドはマルチキャストデータパケットにのみ含まれる。当該フィールドはユニキャストデータパケットには含まれない。
DestSetHash(24):一連の所望の送信先ノードのハッシュ値に基づいて計算される一意の値を含む。このフィールドはマルチキャストデータパケットにのみ含まれる。当該フィールドはユニキャストデータパケットには含まれない。
リンクデータパケットの署名セクション
リンクデータパケットの署名セクションは、パケットデータのセキュアチェックサムとして機能し、更にデータ送信側の認証に利用される。データパケットの送信側であるノードAは、データのハッシュ値、及び受信側に使用されるデフィー・へルマンキー−h(k,D,k)−を計算し、そしてハッシュ値及びキーをリンクデータパケットヘッダのSigフィールドに格納する。ノードBがパケットを受信すると、当該ノードはハッシュ関数hを文字列k,D,kに適用し、そして結果がSigフィールドの内容に一致することを検証する。2つが一致する場合、ノードBは、到着したデータが破損していない確率が高い(h(k,D,k)がチェックサムとして表示されるので)ことを認識し、そして当該ノードは更に、(ノードAのみがkの値を認識しているので)データがノードAから到着しているはずであることを認識する。
リンクデータパケットの署名セクションは、パケットデータのセキュアチェックサムとして機能し、更にデータ送信側の認証に利用される。データパケットの送信側であるノードAは、データのハッシュ値、及び受信側に使用されるデフィー・へルマンキー−h(k,D,k)−を計算し、そしてハッシュ値及びキーをリンクデータパケットヘッダのSigフィールドに格納する。ノードBがパケットを受信すると、当該ノードはハッシュ関数hを文字列k,D,kに適用し、そして結果がSigフィールドの内容に一致することを検証する。2つが一致する場合、ノードBは、到着したデータが破損していない確率が高い(h(k,D,k)がチェックサムとして表示されるので)ことを認識し、そして当該ノードは更に、(ノードAのみがkの値を認識しているので)データがノードAから到着しているはずであることを認識する。
ハッシュ値の折り返し
図15は、ハッシュ値を折り返す方法を示すブロック図である。標準のハッシュ関数の出力−−例えば、MD−5−−は、128ビットハッシュ値である。このハッシュ値を、折り返しと呼ばれるプロセスによって折り返して32ビットの値にする。128ビットハッシュ値h128を32ビットの値h32に折り返すために、排他的論理和演算子をビットごとに、h128の4つの32ビットの部分文字列に適用する。更に正確には:
図15は、ハッシュ値を折り返す方法を示すブロック図である。標準のハッシュ関数の出力−−例えば、MD−5−−は、128ビットハッシュ値である。このハッシュ値を、折り返しと呼ばれるプロセスによって折り返して32ビットの値にする。128ビットハッシュ値h128を32ビットの値h32に折り返すために、排他的論理和演算子をビットごとに、h128の4つの32ビットの部分文字列に適用する。更に正確には:
この様子を更に図式的に見るために、h128が図15の最上部に示す文字列であると仮定する。図15の4つの32ビットの文字列の積層構造として示される4つの32ビットの部分文字列を並べ直すことにより、単一の32ビットハッシュ値を、各コラムに含まれる4ビットをビットごとに排他的論理和演算した結果として取得することができる。h128における296個の異なるハッシュ値を折り返してh32における単一のハッシュ値とするが、h32の232個の異なるハッシュ値は、単純にハッシュ値を推定することによって或るノードになりすますという操作を困難にするように作用する。
リンクデータパケットの署名セクションに含まれるフィールド
図16は、データリンクパケットの署名フィールドセクションを示すブロック図である。Sig(32)はデータのセキュアチェックサムとして機能し、そしてデータ送信側の認証を行なう。ノードAはこのフィールドを、32ビット折り返し文字列h(k,D,k)に設定し、この場合、hは合意したハッシュ関数であり、kはリンクのデフィー・へルマンキーであり、そしてDはパケットの内、パケットヘッダの後に続くデータを表わす。これに関連して、コンマは連結演算子を表わす。ユニキャストデータパケットはSigフィールドを一つだけ持つのに対して、マルチキャストデータパケットは複数のSigフィールドを有することができ、この場合、署名の実際の数は、パケットのマルチキャストセクションに含まれるNumSigsフィールドによって与えられる(図14参照)。
図16は、データリンクパケットの署名フィールドセクションを示すブロック図である。Sig(32)はデータのセキュアチェックサムとして機能し、そしてデータ送信側の認証を行なう。ノードAはこのフィールドを、32ビット折り返し文字列h(k,D,k)に設定し、この場合、hは合意したハッシュ関数であり、kはリンクのデフィー・へルマンキーであり、そしてDはパケットの内、パケットヘッダの後に続くデータを表わす。これに関連して、コンマは連結演算子を表わす。ユニキャストデータパケットはSigフィールドを一つだけ持つのに対して、マルチキャストデータパケットは複数のSigフィールドを有することができ、この場合、署名の実際の数は、パケットのマルチキャストセクションに含まれるNumSigsフィールドによって与えられる(図14参照)。
リンクデータパケットのパケット情報セクション
一旦、ノードA及びBが互いにリンクを設定すると、ノードAからBに送信される複数のパケットに、Packet ID(PID)を連番(0,1,2...)で付加する。同じようにして、ノードBからAに送信される複数のパケットにも、当該パケット固有のPIDに対応する別の順番を使用して、番号を連番で付加する。
一旦、ノードA及びBが互いにリンクを設定すると、ノードAからBに送信される複数のパケットに、Packet ID(PID)を連番(0,1,2...)で付加する。同じようにして、ノードBからAに送信される複数のパケットにも、当該パケット固有のPIDに対応する別の順番を使用して、番号を連番で付加する。
リプライ攻撃からの保護を確実に行なうために、リンクレイヤは、HighestPIDよりも小さいPID、またはHighestPID+RangePIDよりも大きいPIDで到着するパケットを廃棄し、この場合、HighestPIDは、これまでに全てのリンクデータパケットに含まれて受信されたPIDの最大値であり、そしてRangePIDの代表的な定数値は1000である。いずれの実施形態においても、適切な調整を行なって「ラップアラウンド(循環)」を処理する、すなわち全てが1のビットパターンを持つPIDから、全てが0のビットパターンを持つPIDへの円滑な移行を可能にする必要がある。PIDが符号無しの32ビット整数フィールドであり、数値処理が232を法として行なわれるので、この操作が必要である。
リンクデータパケットのパケット情報セクションに含まれるフィールド
図17は、リンクデータパケットのパケット情報セクションを示すブロック図である。PID(32):リンクの寿命に亘って送信される各パケットごとに(リンクに関して、方向に関して)順にインクリメントする整数。
図17は、リンクデータパケットのパケット情報セクションを示すブロック図である。PID(32):リンクの寿命に亘って送信される各パケットごとに(リンクに関して、方向に関して)順にインクリメントする整数。
NumAcks(8):この(発信)パケットに含まれる、着信パケットに対する確認応答の数。更なる情報については、「リンクデータパケットの確認応答セクション」を参照されたい。
ToS(2):リンク経由で渡されるデータに対応するサービスのタイプを指定する。現在サポートされているToSタイプは表1に示される。
Type(8):表2に示すように、パケットに含まれるデータのタイプを記述する。このフィールドは、パケットが確認応答のみを含む場合に0に設定される。それ以外の場合、このフィールドは、上位のプロトコルレイヤのために利用することができる。
AckCom(1):確認応答の圧縮が行なわれる場合に1に設定され、これは、確認応答が32ビット長ではなく8ビット長であることを意味する。それ以外の場合、0に設定される。更なる情報については、「リンクデータパケットの確認応答セクション」を参照されたい。
Res(6):将来時点で使用するために確保される。
リンクデータパケットのフラグメンテーションセクション
図18は、リンクデータパケットのフラグメンテーションセクションを示すブロック図である。
リンクデータパケットのフラグメンテーションセクション
図18は、リンクデータパケットのフラグメンテーションセクションを示すブロック図である。
リンクレイヤプロトコルは、リンクデータパケットフラグメンテーションと呼ばれるプロセスをサポートする。リンクレイヤがパケットを回線レイヤ及びルーティングレイヤから受信すると、パケットはネットワークインターフェースレイヤには大き過ぎてハンドリングすることができない。この現象が生じるのは、ハードウェアに関連する最大送信単位(MTU)制限があるためである。この場合、リンクレイヤは、当該レイヤで受信するパケットを小さいパケット群に、これらのパケットをネットワークインターフェースに送信する前にフラグメント化する。同様に、リンクレイヤがこのようなフラグメント化パケットを受信すると、当該リンクレイヤはこれらのパケットを元のパケット構造に、これらのパケットをルーティングレイヤ及び回線レイヤに渡す前にフォーマットし直す。MTUは、下位のネットワークトランスポート技術がサポートすることができる最大パケットサイズであり、イーサネット、衛星、WiFi,及び無線搬送のような異なる技術に応じて変化する。
相対的に上位の単一パケット−回線レイヤパケットのような−フラグメントを含む全てのパケットが同じPIDを含む。受信側ノードはこのPIDに対する確認応答を、フラグメントの全てを受信した後にのみ送信する。
各データパケットフラグメントは、相対的に上位のパケット内における当該フラグメントの位置を表わすオフセットを含む。これらのオフセットは、最後のフラグメントを示すビットとともに、受信側によるフラグメントの再組立てを可能にするように作用する。
パケット情報セクションのFragフィールド(図17参照)は、現在のデータパケットが大規模なデータブロックのフラグメントであるかどうかを表わす。パケットフラグメンテーションに関連する残りのフィールドを図18に示す。
リンクデータパケットのフラグメンテーションセクションに含まれるフィールド
LastFrag(1):パケットが一連のフラグメントの最後のフラグメントを含む場合に1に設定する。それ以外の場合、0に設定する。
LastFrag(1):パケットが一連のフラグメントの最後のフラグメントを含む場合に1に設定する。それ以外の場合、0に設定する。
Fragmentation Offset(31):元のデータパケットの先頭からのこのフラグメントのオフセットをバイト数で指定するバイトオフセットに設定する。
リンクデータパケットの確認応答セクション
リンクレイヤはパケットを、着信パケットに対する−所与の制限値を最大とする、時間制限内及び空間制限内のできる限り多くの着信パケットに対する−確認応答を発信パケットに乗せるシステムを使用することにより承認する。発信パケットを送信する状態になっている場合、リンクレイヤは、利用可能な確認応答を乗せる。確認応答を利用することができるが、発信する状態になっているパケットが無い場合、リンクレイヤは、2つのイベントの内の一方のイベントを待機する必要がある。
・所与の制限時間が経過した
・所与の数の確認応答が蓄積される
どのステートが生じるかどうかに関係なく、リンクレイヤは、どの有効データストリームにも関連しない空パケットを生成し、待機中の確認応答を乗せ、そしてパケットを送信する。
リンクデータパケットの確認応答セクション
リンクレイヤはパケットを、着信パケットに対する−所与の制限値を最大とする、時間制限内及び空間制限内のできる限り多くの着信パケットに対する−確認応答を発信パケットに乗せるシステムを使用することにより承認する。発信パケットを送信する状態になっている場合、リンクレイヤは、利用可能な確認応答を乗せる。確認応答を利用することができるが、発信する状態になっているパケットが無い場合、リンクレイヤは、2つのイベントの内の一方のイベントを待機する必要がある。
・所与の制限時間が経過した
・所与の数の確認応答が蓄積される
どのステートが生じるかどうかに関係なく、リンクレイヤは、どの有効データストリームにも関連しない空パケットを生成し、待機中の確認応答を乗せ、そしてパケットを送信する。
確認応答の圧縮を使用する(パケット情報セクションのAckComフィールドをセットすることにより;図17参照)場合、確認応答されるパケットのPIDの中の8個の最下位ビットのみが使用される。送信側ノードが、当該ノードが送信した256個の直近のパケットに含まれるパケットに対するackを受信する限り、ノードは、どのパケットが確認応答されているかについて高い精度で判断することができる。
リンクデータパケットの確認応答セクションに含まれるフィールド
図19は、リンクデータパケットの確認応答セクションに含まれるフィールドを示すブロック図である。Ack(8または32):確認応答される受信着信パケットのPIDを含む。フィールドのサイズは8ビットまたは32ビットであり、いずれのビットになるかは、パケット情報セクション(図17参照)に含まれるAckComフィールドの値によって変わる。表示されるAckフィールドの数値は、NumAcksフィールド(このフィールドもパケット情報セクションに含まれる)によって与えられる。
Average Hold Time(32):このパケットで確認応答される複数のパケットの各パケットのホールド時間の平均値を含む。このフィールドは、サービス品質を測定するために使用される。
図19は、リンクデータパケットの確認応答セクションに含まれるフィールドを示すブロック図である。Ack(8または32):確認応答される受信着信パケットのPIDを含む。フィールドのサイズは8ビットまたは32ビットであり、いずれのビットになるかは、パケット情報セクション(図17参照)に含まれるAckComフィールドの値によって変わる。表示されるAckフィールドの数値は、NumAcksフィールド(このフィールドもパケット情報セクションに含まれる)によって与えられる。
Average Hold Time(32):このパケットで確認応答される複数のパケットの各パケットのホールド時間の平均値を含む。このフィールドは、サービス品質を測定するために使用される。
マルチキャストをユニキャストから区別する
概要が以下の疑似コードに示されるプロシージャOnReceiveDataPacket()は、リンクレイヤが、ユニキャストパケットをマルチキャストデータパケットから区別する方法を記述する。この処理はPALで行なわれる。送信側がマルチキャストを行なおうとしている場合、送信側は、一連の所望の受信側によって導出される値DestSetHashを計算する(DestSetHash値に関する更に詳しい情報については、「リンクデータパケットのマルチキャストセクション」を参照されたい)。パケットを物理的に受信する各ノードは、当該ノードが送信側の所望の受信側の内の一つの受信側であるかどうかを、パケットヘッダに含まれる署名を調査することにより判断することができるが、DestSetHash値は、ローカルノードが所望の受信側であるかどうかを、パケットヘッダに含まれる署名のリストを全てを必ず調査しなければならないという必要を無くすことにより、更に迅速に判断する手段となる。
概要が以下の疑似コードに示されるプロシージャOnReceiveDataPacket()は、リンクレイヤが、ユニキャストパケットをマルチキャストデータパケットから区別する方法を記述する。この処理はPALで行なわれる。送信側がマルチキャストを行なおうとしている場合、送信側は、一連の所望の受信側によって導出される値DestSetHashを計算する(DestSetHash値に関する更に詳しい情報については、「リンクデータパケットのマルチキャストセクション」を参照されたい)。パケットを物理的に受信する各ノードは、当該ノードが送信側の所望の受信側の内の一つの受信側であるかどうかを、パケットヘッダに含まれる署名を調査することにより判断することができるが、DestSetHash値は、ローカルノードが所望の受信側であるかどうかを、パケットヘッダに含まれる署名のリストを全てを必ず調査しなければならないという必要を無くすことにより、更に迅速に判断する手段となる。
プロシージャOnReceiveDataPacket()では、変数DestSetTableは、DestSetHashの値をインデックスとして付与されたアレイである。各エントリは符号無しの整数値を含む。ローカルノードは、DestSetTable[DestSetHash]が非ゼロである場合に、DestSetHashの状態であり、この場合、DestSetTable[DestSetHash]の値は、ローカルノードの署名に一致する必要がある署名の位置(データパケットヘッダに付加された一連の署名の中の)を示す。DestSetTable[DestSetHash]の値がゼロである場合、ローカルノードは所望の受信側ではなく、当該ノードはパケットを廃棄する必要がある。
DestSetTable[DestSetHash]の値は、ローカルノードが、値DestSetHashをパケットのDestSetHashフィールドに含むパケットを受信した後にのみ定義される。ローカルノードが当該パケットを受信する前では、DestSetTable[DestSetHash]は定義されない。送信側が、異なる一連の所望の送信先を持つパケットをブロードキャストする場合、送信側はDestSetHashの新規の値を、送信側が送信するデータパケットのDestSetHashフィールドに関して計算する。ローカルノードが、新規のDestSetHash値を含むマルチキャストパケットを受信する場合、当該ノードは、当該ノードの署名を計算し、そしてパケットヘッダに含まれる複数の署名の中から一致する署名を調査する。一致を示す署名の位置をDestSetTable[DestSetHash]に格納する。署名が一致しない場合には、DestSetTable[DestSetHash]がゼロに設定され、そしてパケットが廃棄される。
リンクレイヤは、データをリンクで送信するコストをモニタリングする。幾つかの一般的なコスト指標は、帯域、遅延、ジッタ、信頼性、輻輳、及び実際の金銭費用(例えば、ネットワークでは衛星リンクの使用をリースすることができる)を含む。回線レイヤはこのデータを使用して、ユーザが指定するQoS要件を満たす回線を設定する。
getQoS()
getQoS()関数は一連のQoS指標を返す。返される指標は、特定の実施形態に限定される。
getQoS()関数は一連のQoS指標を返す。返される指標は、特定の実施形態に限定される。
パケット配信
パケットは上位プロトコルレイヤに、ReceivePacket(図3参照)に対する呼び出しを行なうことにより配信される。パケットが、テストパケットまたは広告に設定された当該パケットのTypeフィールドを持つ場合(表2、及び「リンクデータパケットのパケット情報セクション」と題する節を参照)、リンクデータレイヤは、ルーティングレイヤのReceivePacketを呼び出す。パケットが、複数の回線関連パケットタイプ(表2参照)の内の一つの回線関連パケットタイプに設定されたタイプフィールドを持つ場合、リンクデータレイヤは、回線レイヤのReceivePacketを呼び出す。
パケットは上位プロトコルレイヤに、ReceivePacket(図3参照)に対する呼び出しを行なうことにより配信される。パケットが、テストパケットまたは広告に設定された当該パケットのTypeフィールドを持つ場合(表2、及び「リンクデータパケットのパケット情報セクション」と題する節を参照)、リンクデータレイヤは、ルーティングレイヤのReceivePacketを呼び出す。パケットが、複数の回線関連パケットタイプ(表2参照)の内の一つの回線関連パケットタイプに設定されたタイプフィールドを持つ場合、リンクデータレイヤは、回線レイヤのReceivePacketを呼び出す。
結論
リンクレイヤプロトコルは、複数のCoCoノードペアの間の直接的接続手段であるリンクを生成し、そして管理する。リンクレイヤは、隣接するCoCoデバイスの存在を検出し、そしてこれらのデバイスに達するリンクを設定する。リンク設定では、符号化方式の交渉及びデフィー・へルマンキー交換を行なって、リンク経由で送信される全ての通信の安全を確保することができるようにする。
リンクレイヤプロトコルは、複数のCoCoノードペアの間の直接的接続手段であるリンクを生成し、そして管理する。リンクレイヤは、隣接するCoCoデバイスの存在を検出し、そしてこれらのデバイスに達するリンクを設定する。リンク設定では、符号化方式の交渉及びデフィー・へルマンキー交換を行なって、リンク経由で送信される全ての通信の安全を確保することができるようにする。
一旦、リンクが設定されると、リンクレイヤは、パケットの受け渡しをネットワークインターフェースレイヤと上位のプロトコルレイヤとの間で行ない、サービス品質(QoS)統計をモニタリングし、これらの統計を上位のプロトコルレイヤにレポートすることができる。リンクレイヤは、マルチキャストを、単一のネットワークインターフェースを経由する冗長なパケット転送を抑制することによりサポートし、パケットサイズがネットワークインターフェースの最大送信単位(MTU)を超える場合にフラグメンテーションを実行し、無効リンクを閉鎖して、システムリソースを新規のリンクリクエストのために解放する。
リンクレイヤは、デフィー・へルマンキー交換、及びワークトークン計算を使用して、TCP及びIPには組み込まれていないセキュリティのレベルを実現する。このプロトコルは、移動体ネットワーク技術及びアドホックネットワーク技術のために特に設計され、そしてこの目的に対応するTCP/IPよりも優れる。
以下の項目が可能になる。
1.リンクを、スケーラブルかつ動的な性質を有する異機種環境通信ネットワークにおいて設定する方法。
2.他のネットワークノードの存在を通信ネットワークにおいて検出する方法。
3.他のネットワークノードを含むリンクの安全を確保する方法。ノードA及びBが、一つのリンクによって接続される2つのネットワークノードである場合、ノードAがパケットをノードBに送信すると、ノードBは、ノードAだけが当該パケットを送信することができることを保証され、そしてノードAは、ノードBだけが当該パケットを読み取ることができることを保証される。
4.介入者攻撃を防止する方法。一旦、リンクが2つのノードAとBとの間に設定されると、不良ノードは、当該ノード自体をノードAとBとの間に介在させ、そしてノードA及びBの各々に対して他方のノードになりすますということはできなくなる。従って、CoCoネットワークは、所謂介入者攻撃を防止する。
5.サービス拒否攻撃を防止する方法。ネットワークを偽パケットで溢れさせようと試みるノードは必ず、膨大な計算リソースを利用せざるを得なくなる。従って、CoCoネットワークは、所謂サービス拒否攻撃を防止する。
6.リンク品質を通信ネットワークにおいてモニタリングする方法。
7.測定リンク品質を使用して、指定QoS要件を満たす回線を通信ネットワークにおいて設定する方法。
8.一様なアドレス(一様なネットワーク識別子)をネットワークノードに、異機種環境通信ネットワークにおいて割り当てる方法。
9.ノード群が適切なセキュリティ機構についてリンク設定中に交渉する方法。
10.マルチキャストを、単一のネットワークインターフェースを経由する冗長なパケット転送を抑制することによりサポートする方法。
11.リンクを閉鎖する必要がある時点を検出する方法。
1.リンクを、スケーラブルかつ動的な性質を有する異機種環境通信ネットワークにおいて設定する方法。
2.他のネットワークノードの存在を通信ネットワークにおいて検出する方法。
3.他のネットワークノードを含むリンクの安全を確保する方法。ノードA及びBが、一つのリンクによって接続される2つのネットワークノードである場合、ノードAがパケットをノードBに送信すると、ノードBは、ノードAだけが当該パケットを送信することができることを保証され、そしてノードAは、ノードBだけが当該パケットを読み取ることができることを保証される。
4.介入者攻撃を防止する方法。一旦、リンクが2つのノードAとBとの間に設定されると、不良ノードは、当該ノード自体をノードAとBとの間に介在させ、そしてノードA及びBの各々に対して他方のノードになりすますということはできなくなる。従って、CoCoネットワークは、所謂介入者攻撃を防止する。
5.サービス拒否攻撃を防止する方法。ネットワークを偽パケットで溢れさせようと試みるノードは必ず、膨大な計算リソースを利用せざるを得なくなる。従って、CoCoネットワークは、所謂サービス拒否攻撃を防止する。
6.リンク品質を通信ネットワークにおいてモニタリングする方法。
7.測定リンク品質を使用して、指定QoS要件を満たす回線を通信ネットワークにおいて設定する方法。
8.一様なアドレス(一様なネットワーク識別子)をネットワークノードに、異機種環境通信ネットワークにおいて割り当てる方法。
9.ノード群が適切なセキュリティ機構についてリンク設定中に交渉する方法。
10.マルチキャストを、単一のネットワークインターフェースを経由する冗長なパケット転送を抑制することによりサポートする方法。
11.リンクを閉鎖する必要がある時点を検出する方法。
関連するセマンティックのコンセプト
・リンク
・帯域
・遅延
・暗号化
・デフィー・へルマンキー合意
・ユニバーサルノード識別子
・プロトコル抽象化レイヤ
・サービス拒否攻撃の防止
・介入者攻撃の防止
・リンク設定パケット
・往復時間の計算
・確認応答
・マルチキャスト処理
・ユニキャスト処理
・リンクステートマシン
これまでの記述から、本発明の特定の実施形態について本明細書において説明して例示を行なってきたが、種々の変更を本発明の技術思想及び技術範囲から逸脱しない限り加え得ることを理解できるであろう。従って、本発明は、添付の請求項によって規定される以外には制限されない。
・リンク
・帯域
・遅延
・暗号化
・デフィー・へルマンキー合意
・ユニバーサルノード識別子
・プロトコル抽象化レイヤ
・サービス拒否攻撃の防止
・介入者攻撃の防止
・リンク設定パケット
・往復時間の計算
・確認応答
・マルチキャスト処理
・ユニキャスト処理
・リンクステートマシン
これまでの記述から、本発明の特定の実施形態について本明細書において説明して例示を行なってきたが、種々の変更を本発明の技術思想及び技術範囲から逸脱しない限り加え得ることを理解できるであろう。従って、本発明は、添付の請求項によって規定される以外には制限されない。
Claims (3)
- スケーラブルかつ動的である異機種環境通信ネットワークにおいてリンクを設定するシステムであって、
(a)データを互いに送信および受信することができる通信デバイスの集合体を有する通信ネットワークと、
(b)複数タイプのネットワークデバイス、及び複数タイプの通信リンクの集合体を有し、かつ異なるタイプ及び製造業者のデバイスを含むハイブリッドネットワークである異機種環境通信ネットワークと、
(c)フレームをネットワークインターフェースレイヤで送受信し、データを回線/ルーティングレイヤで送受信するプロトコル抽象化レイヤと
を備え、前記プロトコル抽象化レイヤは、リンク設定レイヤコンポーネント、サービス品質ハンドラーコンポーネント、及びリンクデータレイヤコンポーネントを有する、システム。 - 前記プロトコル抽象化レイヤは、ネットワークデバイスからデータフレームを受信し、CoCoヘッダ及びアドレス変換テーブルを作成し、ネットワークインターフェースレイヤヘッダを削除し、前記CoCoヘッダを有する変更済みパケットをサブレイヤに送信する、請求項1記載のシステム。
- 前記作成したCoCoヘッダ及びアドレス変換テーブルには、ネットワークインターフェースレイヤからの情報を格納する、請求項2記載のシステム。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US76395906P | 2006-02-01 | 2006-02-01 | |
PCT/US2007/061487 WO2007090196A2 (en) | 2006-02-01 | 2007-02-01 | Protocol link layer |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2009525708A true JP2009525708A (ja) | 2009-07-09 |
Family
ID=38328165
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008553515A Withdrawn JP2009525708A (ja) | 2006-02-01 | 2007-02-01 | プロトコルリンクレイヤ |
Country Status (7)
Country | Link |
---|---|
US (4) | US20100002721A1 (ja) |
EP (1) | EP1985047A2 (ja) |
JP (1) | JP2009525708A (ja) |
CN (1) | CN101411105A (ja) |
CA (1) | CA2641253A1 (ja) |
IL (1) | IL193162A0 (ja) |
WO (1) | WO2007090196A2 (ja) |
Families Citing this family (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2242220A1 (en) * | 2008-01-10 | 2010-10-20 | Sumitomo Electric Networks, Inc. | Network card and information processor |
US20110196964A1 (en) * | 2008-10-14 | 2011-08-11 | Srikanth Natarajan | Managing event traffic in a network system |
JP5728249B2 (ja) | 2011-02-25 | 2015-06-03 | 任天堂株式会社 | 情報処理システム、情報処理装置、情報処理プログラム、および、情報処理方法 |
JP5707171B2 (ja) | 2011-02-25 | 2015-04-22 | 任天堂株式会社 | 通信制御装置、通信制御プログラム、通信制御方法、および、情報処理システム |
EP2500872A1 (fr) * | 2011-03-08 | 2012-09-19 | Openways Sas | Procédé sécurisé de commande d'ouverture de dispositifs de serrure par un objet communicant de type téléphone portable |
US8971213B1 (en) * | 2011-10-20 | 2015-03-03 | Cisco Technology, Inc. | Partial association identifier computation in wireless networks |
CN102420764B (zh) * | 2011-12-08 | 2015-02-25 | 北京星网锐捷网络技术有限公司 | 一种链路建立方法及设备 |
CN103428690B (zh) * | 2012-05-23 | 2016-09-07 | 华为技术有限公司 | 无线局域网络的安全建立方法及***、设备 |
EP2747348A1 (en) | 2012-12-20 | 2014-06-25 | Thomson Licensing | Apparatus adapted for connecting a home network with a service provider network |
CN103414603B (zh) * | 2013-07-31 | 2016-08-10 | 清华大学 | 基于Hash折叠方法的Ipv6深度包检测方法 |
US10057765B2 (en) * | 2014-09-04 | 2018-08-21 | Samsung Electronics Co., Ltd. | Master node and operation method of the master node |
KR102280286B1 (ko) * | 2014-09-04 | 2021-07-22 | 삼성전자주식회사 | 마스터 노드 및 마스터 노드의 동작 방법 |
US20160085975A1 (en) * | 2014-09-18 | 2016-03-24 | Safenet, Inc. | Constrained Information Transfer |
US10326590B2 (en) * | 2014-11-11 | 2019-06-18 | Intel Corporation | Technologies for trusted device on-boarding |
US9660768B2 (en) | 2015-01-26 | 2017-05-23 | Link Labs, Inc. | Dense acknowledgement broadcast/multicast |
US10498832B2 (en) * | 2017-07-11 | 2019-12-03 | Oracle International Corporation | Link-training auto-negotiation protocol with three-way handshake |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5511122A (en) | 1994-06-03 | 1996-04-23 | The United States Of America As Represented By The Secretary Of The Navy | Intermediate network authentication |
US7512799B1 (en) * | 1999-03-05 | 2009-03-31 | Getthere Inc. | System and method for accessing a remote server from an intranet with a single sign-on |
US6584466B1 (en) * | 1999-04-07 | 2003-06-24 | Critical Path, Inc. | Internet document management system and methods |
US7278017B2 (en) | 2000-06-07 | 2007-10-02 | Anoto Ab | Method and device for secure wireless transmission of information |
US6947431B1 (en) * | 2000-08-23 | 2005-09-20 | Radio Ip Software Inc. | Wireless data communications with header suppression and reconstruction |
US7173927B2 (en) * | 2000-12-18 | 2007-02-06 | Raza Microelectronics, Inc. | Hybrid network to carry synchronous and asynchronous traffic over symmetric and asymmetric links |
JP3757933B2 (ja) * | 2002-11-28 | 2006-03-22 | ソニー株式会社 | 通信装置 |
US7451217B2 (en) * | 2002-12-19 | 2008-11-11 | International Business Machines Corporation | Method and system for peer-to-peer authorization |
US9331990B2 (en) * | 2003-12-22 | 2016-05-03 | Assa Abloy Ab | Trusted and unsupervised digital certificate generation using a security token |
US20050235140A1 (en) * | 2004-03-11 | 2005-10-20 | Hui Chi-Kwong | System and method for secure preservation and long term archival of electronic documents |
US7720864B1 (en) * | 2004-03-25 | 2010-05-18 | Symantec Operating Corporation | Expiration of access tokens for quiescing a distributed system |
US7844674B2 (en) * | 2004-12-03 | 2010-11-30 | Clairmail Inc. | Architecture for general purpose trusted personal access system and methods therefor |
US7870201B2 (en) * | 2004-12-03 | 2011-01-11 | Clairmail Inc. | Apparatus for executing an application function using a mail link and methods therefor |
US7870202B2 (en) * | 2004-12-03 | 2011-01-11 | Clairmail Inc. | Apparatus for executing an application function using a smart card and methods therefor |
US7577096B2 (en) * | 2005-02-18 | 2009-08-18 | Broadcom Corporation | Timestamp metering and rollover protection in a network device |
US7529191B2 (en) * | 2005-02-18 | 2009-05-05 | Broadcom Corporation | Programmable metering behavior based on table lookup |
US20070174630A1 (en) * | 2005-02-21 | 2007-07-26 | Marvin Shannon | System and Method of Mobile Anti-Pharming and Improving Two Factor Usage |
US8566462B2 (en) * | 2005-05-12 | 2013-10-22 | Digital River, Inc. | Methods of controlling access to network content referenced within structured documents |
US20060274695A1 (en) * | 2005-06-03 | 2006-12-07 | Nokia Corporation | System and method for effectuating a connection to a network |
US7930736B2 (en) * | 2006-01-13 | 2011-04-19 | Google, Inc. | Providing selective access to a web site |
-
2007
- 2007-02-01 EP EP07762868A patent/EP1985047A2/en not_active Withdrawn
- 2007-02-01 JP JP2008553515A patent/JP2009525708A/ja not_active Withdrawn
- 2007-02-01 CA CA002641253A patent/CA2641253A1/en not_active Abandoned
- 2007-02-01 CN CNA2007800109534A patent/CN101411105A/zh active Pending
- 2007-02-01 WO PCT/US2007/061487 patent/WO2007090196A2/en active Application Filing
- 2007-02-01 US US12/278,145 patent/US20100002721A1/en not_active Abandoned
-
2008
- 2008-07-31 IL IL193162A patent/IL193162A0/en unknown
-
2012
- 2012-02-16 US US13/398,751 patent/US8248964B2/en active Active
- 2012-08-16 US US13/587,661 patent/US8861393B2/en active Active
-
2014
- 2014-10-13 US US14/512,690 patent/US9641492B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US20130051401A1 (en) | 2013-02-28 |
US8861393B2 (en) | 2014-10-14 |
US20150100790A1 (en) | 2015-04-09 |
US9641492B2 (en) | 2017-05-02 |
WO2007090196A2 (en) | 2007-08-09 |
IL193162A0 (en) | 2009-02-11 |
CA2641253A1 (en) | 2007-08-09 |
CN101411105A (zh) | 2009-04-15 |
US20120151069A1 (en) | 2012-06-14 |
US8248964B2 (en) | 2012-08-21 |
US20100002721A1 (en) | 2010-01-07 |
WO2007090196A3 (en) | 2007-12-27 |
EP1985047A2 (en) | 2008-10-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9641492B2 (en) | Protocol link layer | |
Kumar et al. | Implementation and analysis of QUIC for MQTT | |
US8224976B2 (en) | Using a server's capability profile to establish a connection | |
US7502860B1 (en) | Method and apparatus for client-side flow control in a transport protocol | |
TWI677222B (zh) | 應用於伺服器負載均衡中的連接建立方法及裝置 | |
US7921282B1 (en) | Using SYN-ACK cookies within a TCP/IP protocol | |
US10355961B2 (en) | Network traffic capture analysis | |
Lu et al. | Delay/disruption tolerant network and its application in military communications | |
Thornburgh | Adobe's Secure Real-Time Media Flow Protocol | |
WO2011029357A1 (zh) | 认证通信流量的方法、通信***和防护装置 | |
Simpson | TCP cookie transactions (TCPCT) | |
Seggelmann et al. | SSH over SCTP—Optimizing a multi-channel protocol by adapting it to SCTP | |
Bernardo et al. | A conceptual approach against next generation security threats: Securing a high speed network protocol-UDT | |
Custura et al. | Reducing the acknowledgement frequency in IETF QUIC | |
Smyslov | Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation | |
CN115242353B (zh) | 用于更新无线网格网络中重传次数的方法和设备 | |
Jerschow et al. | Secure client puzzles based on random beacons | |
Kumar et al. | Data sequence map flooding in MPTCP framework: Potential challenges and efficient countermeasures | |
CN117978374A (zh) | 一种安全路由发现方法和*** | |
Thornburgh | RFC 7016: Adobe's Secure Real-Time Media Flow Protocol | |
Simpson | RFC 6013: TCP Cookie Transactions (TCPCT) | |
KR101333153B1 (ko) | TLS 복호화 기능을 포함하는 VoIP 보안장비 | |
Choudhari et al. | Performance Evaluation of SCTP-Sec: A Secure SCTP Mechanism | |
JP2007174293A (ja) | 通信装置 | |
Smyslov | RFC 7383: Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100201 |
|
A072 | Dismissal of procedure [no reply to invitation to correct request for examination] |
Free format text: JAPANESE INTERMEDIATE CODE: A073 Effective date: 20110628 |
|
A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20110705 |