JP2006067057A - ネットワーク機器、Ｒａｄｉｕｓクライアント、有線ＬＡＮ認証システム、認証パケット透過方法、制御プログラム、記録媒体及びサプリカント - Google Patents

Abstract

【課題】ＩＥＥＥ８０２．１ｘ認証において、サプリカントから送信される認証パケットの転送処理を行うネットワーク機器、１つの物理インタフェース当たり複数のＩＥＥＥ８０２．１ｘ認証を可能にするＲａｄｉｕｓクライアント、それらを備えた有線ＬＡＮ認証システムを提供する。
【解決手段】サプリカントが接続される物理インタフェースと、Ｒａｄｉｕｓクライアントから送信される認証パケットのヘッダ情報を解析する解析部と、解析した結果に基づき所定の動作を行う制御部とをネットワーク機器に備える。また、物理インタフェースと、物理インタフェース毎に複数の認証インタフェースをＲａｄｉｕｓクライアントに備える。
【選択図】図８

Description

本発明は、ＩＥＥＥ８０２．１ｘ認証パケットを透過するネットワーク機器、物理インターフェース当たり複数のサプリカントのＩＥＥＥ８０２．１ｘ認証を可能にするＲａｄｉｕｓクライアント、及びそれらを備えた有線ＬＡＮ認証システム、ＩＥＥＥ８０２．１ｘ認証パケット透過方法、制御プログラム、記録媒体、サプリカントに関するものである。

ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃ Ｅｎｇｉｎｅｅｒｓ：米国電気電子学会）が規格したＩＥＥＥ８０２．１ｘ認証技術は、ユーザ認証の規格である。ＩＥＥＥ８０２．１ｘ認証技術はＭｉｃｒｏｓｏｆｔ社がＷｉｎｄｏｗｓ（登録商標）プラットフォームで採用したこともあり、無線通信認証・暗号化手段のデファクトスタンダードとなりつつある。例えば、特許文献１のようにＩＥＥＥ８０２．１ｘに基づいて認証を行うインターネット中継装置がある。

ＩＥＥＥ８０２．１ｘ認証技術はＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）等のプロトコルを拡張したＥＡＰ（Ｅｘｔｅｎｓｉｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：拡張可能認証プロトコル）とユーザ名、パスワード、デジタル証明書などと組み合わせて行う。認証サーバであるＲａｄｉｕｓサーバ（Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ−Ｉｎ Ｕｓｅｒ Ｓｅｒｖｉｃｅ）を併用することで、クライアントとサーバとの認証を行う。

Ｒａｄｉｕｓは、米国Ｌｉｖｉｎｇｓｔｏｎ Ｅｎｔｅｒｐｒｉｓｅｓ社が開発した認証システムであり、データベースに収容されたユーザ情報を元に認証やユーザのアクセス制御等を行うためのプロトコルである。認証する側がＲａｄｉｕｓサーバと呼ばれ、認証要求を出す側がＲａｄｉｕｓクライアントと呼ばれる。

ＲａｄｉｕｓサーバはＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ、Ａｕｔｈｏｒｉｚａｔｉｏｎ、Ａｃｃｏｕｎｔｉｎｇ：認証、承認、使用状況管理）サーバの一種であり、ＡＡＡサーバは、その他の種類に、ＴＡＣＡＣＳ（Ｔｅｒｍｉｎａｌ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌｌｅｒ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ：アクセス管理プロトコル）サーバ等がある。

上述のＥＡＰは、デジタル証明書によって身元を証明するＥＡＰ−ＴＬＳ（ＥＡＰ−Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）やサーバ側でデジタル証明書、クライアント側でユーザ名とパスワードを使うＥＡＰ−ＴＴＬＳ（ＥＡＰ−Ｔｕｎｎｅｌｅｄ ＴＬＳ）等がある。

さらに、ＥＡＰは、サプリカントの認証時にＲａｄｉｕｓクライアントとの間で、宛先のＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ：媒体アクセス制御）アドレス（０１：８０：ｃ２：００：００：０３）のマルチキャストアドレスを使用して、認証を行う。ＥＡＰを使用することで、既存のセキュリティ性より高い無線ＬＡＮシステムが確保できる。例えば、特許文献２のようにＩＥＥＥ８０２．１１に準拠して無線ＬＡＮシステムの認証を行うものがある。

近年では、無線ＬＡＮで普及したＩＥＥＥ８０２．１ｘ認証技術が有線ＬＡＮに応用されている。これは、無線ＬＡＮがネットワークケーブルを使用した有線ＬＡＮと比較して、誰がどこでネットワークを利用しているのかが視覚的につかみにくいためである。即ち、どこにでもすぐにつながる無線ＬＡＮの利便性は、そのまま新たなセキュリティ性の懸念を意味している。

図８は、ＩＥＥＥ８０２．１ｘ認証技術を利用した有線ＬＡＮ認証システムの構成を示す概念図である。

ＩＥＥＥ８０２．１ｘ認証技術を利用した有線ＬＡＮ認証システムは、Ｒａｄｉｕｓサーバ、Ｒａｄｉｕｓサーバとケーブル等で接続されたスイッチ等のＲａｄｉｕｓクライアント、Ｒａｄｉｕｓクライアントとケーブル等で接続されたサプリカントで構成される。なお、サプリカントはＩＥＥＥ８０２．１ｘ認証を行う際に必要なクライアント用のソフトウェア及びＰＣ等の加入者端末を指す。また、Ｒａｄｉｕｓクライアントはネットワーク機器の一部であるが、本明細書中では、ネットワーク機器と記載しているものは、Ｒａｄｉｕｓクライアントとサプリカントとの間に設置されるＲａｄｉｕｓクライアント以外の機器であるものとする。

ネットワーク機器にはスイッチやルータ、Ｂ−ＰＯＮ（Ｂｒｏａｄｂａｎｄ Ｐａｓｓｉｖｅ Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ：ブロードバンドパッシブ光ネットワーク）、やＥ−ＰＯＮ（Ｅｔｈｅｒｎｅｔ（登録商標） ＰＯＮ：イーサネット（登録商標）パッシブ光ネットワーク）等のデータ通信を司る光伝送装置、メディアコンバータ、モデム等がある。また、上述のＲａｄｉｕｓクライアントにはスイッチ、ＲＡＳ（Ｒｅｍｏｔｏ Ａｃｃｅｓｓ Ｓｙｓｔｅｍ：遠隔接続システム）やＢＲＡＳ（Ｂｒｏａｄｂａｎｄ ＲＡＳ：広帯域遠隔接続システム）等がある。
特開２００３−２２４５７７号公報 特開２００１−１１１５４４号公報

上述したように有線ＬＡＮ認証システムを構築する際、サプリカントとＲａｄｉｕｓクライアントの間にスイッチ、ルータ、Ｂ−ＰＯＮやＥ−ＰＯＮ等の光伝送装置、メディアコンバータ、モデム等のネットワーク機器が配置される場合がある。しかしながら、それらのネットワーク機器がレイヤ２以上の制御を行うネットワーク機器である場合、そのネットワーク機器上で認証パケットは廃棄されてしまうというネットワーク機器の問題点がある。

また、有線ＬＡＮ認証システムに使用するスイッチやＲＡＳ等のＲａｄｉｕｓクライアントにもＩＥＥＥ８０２．１ｘ認証技術が実装されつつある。しかし、スイッチやＲＡＳ等のＲａｄｉｕｓクライアントは、１つの物理インタフェース当たり１台のサプリカントしか収容することができないという問題点がある。

さらに、上述したように、Ｒａｄｉｕｓクライアントの物理インタフェース当たり１台のサプリカントの認証を可能にするインタフェース認証の技術が普及しているが、有線ＬＡＮネットワークに応用する場合、サプリカント数と同数以上の物理インタフェース数をＲａｄｉｕｓクライアントに実装する必要がある。例えば、サプリカント数が４つであれば、少なくとも４つ以上の物理インタフェースをＲａｄｉｕｓクライアントに実装しなければならず、さらには、サプリカントとＲａｄｉｕｓクライアントの物理インタフェースとが１対１で接続されなければならない。

そして、仮にサプリカント数と同数以上の物理インタフェース数を満たすＲａｄｉｕｓクライアントであっても、加入者が複数のサプリカントを有する場合、２台目以降のサプリカントの認証が許可されないという問題点もある。

本発明のネットワーク機器の第１の態様は、サプリカントとＲａｄｉｕｓクライアントとの間に備えられたネットワーク機器であって、Ｒａｄｉｕｓクライアントが接続される物理インタフェースと、Ｒａｄｉｕｓクライアントから送信される認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析する解析部と、解析した結果に基づいて、所定の動作を行う制御部とを備えたことを特徴とするネットワーク機器である。

本発明のネットワーク機器の第２の態様は、解析部が、８０２．１ｘ認証パケットを透過または破棄のいずれか１つの動作を行う手段を備えたことを特徴とするネットワーク機器である。

本発明のネットワーク機器の第３の態様は、制御部が、予め設定されたフォワーディングポートに応じて、認証パケットの宛先ＭＡＣアドレスをマルチキャストアドレス、サプリカント又はＲａｄｉｕｓクライアントのＭＡＣアドレス、ブロードキャストアドレスに書き換える手段を備えたことを特徴とするネットワーク機器である。

本発明のネットワーク機器の第４の態様は、制御部が、認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報に含まれるサプリカントまたはＲａｄｉｕｓクライアントのＭＡＣアドレスを記憶し、各々のＭＡＣアドレス宛にユニキャストで送信する手段を備えたことを特徴とするネットワーク機器である。

本発明のＲａｄｉｕｓクライアントの第１の態様は、有線ＬＡＮ認証システム用のＲａｄｉｕｓクライアントであって、物理インタフェースと、前記物理インタフェース毎に複数の認証インタフェースとが備えられたＲａｄｉｕｓクライアントである。

本発明のＲａｄｉｕｓクライアントの第２の態様は、認証インタフェースが論理インタフェースであるＲａｄｉｕｓクライアントである。

本発明のＲａｄｉｕｓクライアントの第３の態様は、認証インタフェースがＶＬＡＮであるＲａｄｉｕｓクライアントである。

本発明のＲａｄｉｕｓクライアントの第４の態様は、認証インタフェースがサブインタフェースであるＲａｄｉｕｓクライアントである。

本発明のＲａｄｉｕｓクライアントの第５の態様は、有線ＬＡＮ認証システム用のＲａｄｉｕｓクライアントであって、物理インタフェースと、前記物理インタフェース毎に認証用アドレスを記憶する認証用アドレス記憶手段とを備えられたＲａｄｉｕｓクライアントである。

本発明の有線ＬＡＮ認証システムの第１の態様は、複数のサプリカントに接続される上述のネットワーク機器と、ネットワーク機器に接続される上述のＲａｄｉｕｓクライアントと、Ｒａｄｉｕｓクライアントに接続されるＲａｄｉｕｓサーバ及びＤＨＣＰサーバとが有線で接続され、さらに、インターネットに接続される有線ＬＡＮ認証システムである。

本発明の認証パケット透過方法の第１の態様は、サプリカントとＲａｄｉｕｓクライアントとの間に備えられたネットワーク機器を認証パケットが透過する認証パケット透過方法であって、Ｒａｄｉｕｓクライアントが物理インタフェースに接続される接続ステップと、Ｒａｄｉｕｓクライアントから送信される認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析する解析ステップと、解析した結果に基づいて、所定の動作を行う制御ステップとを備えたことを特徴とする認証パケット透過方法である。

本発明の認証パケット透過方法の第２の態様は、解析ステップが、認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析し、透過または破棄のいずれか１つの動作を行うステップを備えたことを特徴とする認証パケット透過方法である。

本発明の認証パケット透過方法の第３の態様は、制御ステップが、予め設定されたフォワーディングポートに応じて、認証パケットの宛先ＭＡＣアドレスをマルチキャストアドレス、サプリカント又はＲａｄｉｕｓクライアントのＭＡＣアドレス、ブロードキャストアドレスに書き換える手段を備えたことを特徴とする認証パケット透過方法である。

本発明の認証パケット透過方法の第４の態様は、制御ステップが、認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報に含まれるサプリカントまたはＲａｄｉｕｓクライアントのＭＡＣアドレスを記憶し、各々のＭＡＣアドレス宛にユニキャストで送信するステップを備えたことを特徴とする認証パケット透過方法である。

本発明の制御プログラムの第１の態様は、サプリカントとＲａｄｉｕｓクライアントとの間に備えられたネットワーク機器に対し、ソフトウェア処理により認証パケットの透過を制御する制御プログラムであって、Ｒａｄｉｕｓクライアントを物理インタフェースに接続させ、Ｒａｄｉｕｓクライアントから送信される認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析させ、解析した結果に基づいて、所定の動作を行わせることを特徴とする制御プログラムである。

本発明の制御プログラムの第２の態様は、解析が、透過または破棄のいずれか１つの動作を行わせることを特徴とする制御プログラムである。

本発明の制御プログラムの第３の態様は、制御が、予め設定されたフォワーディングポートに応じて、認証パケットの宛先ＭＡＣアドレスをマルチキャストアドレス、サプリカント又はＲａｄｉｕｓクライアントのＭＡＣアドレス、ブロードキャストアドレスに書き換えさせることを特徴とする制御プログラムである。

本発明の制御プログラムの第４の態様は、制御が、認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報に含まれるサプリカントまたはＲａｄｉｕｓクライアントのＭＡＣアドレスを記憶し、各々のＭＡＣアドレス宛にユニキャストで送信させることを特徴とする制御プログラムである。

本発明の記録媒体の第１の態様は、上述の制御プログラムを記録したコンピュータ読取可能な記録媒体である。

本発明のサプリカントの第１の態様は、認証パケット（ＥＡＰ Ｒｅｑｕｅｓｔ）に含まれるＲａｄｉｕｓクライアントのＭＡＣアドレスを記憶し、Ｒａｄｉｕｓクライアント宛にユニキャストで認証パケット（ＥＡＰ Ｒｅｓｐｏｎｓｅ）を送信するサプリカントである。

本発明のネットワーク機器により、従来は破棄されていたサプリカントまたはＲａｄｉｕｓクライアントからのＩＥＥＥ８０２．１ｘ認証パケットが、ネットワーク機器上で透過、廃棄の設定が可能となり、ＩＥＥＥ８０２．１ｘ認証技術の有線ＬＡＮ認証システムの汎用性が広がることを期待できる。

また、本発明のＲａｄｉｕｓクライアントにより従来は１物理インタフェース当たり１サプリカントの認証しか行えなかったＩＥＥＥ８０２．１ｘ認証技術が、１物理インタフェース当たり複数のサプリカントの認証が可能となり、有線ＬＡＮ認証システムの汎用性が広がることを期待できる。

以下に、本発明の実施形態を図面を参照しながら詳細に説明する。

図１は、本発明のネットワーク機器を表したブロック図である。
図１に示すように、本発明のネットワーク機器１は、物理インタフェース２及び７、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部３、インタフェース制御部４、ＭＡＣアドレスデータベース５、ヘッダ情報変換部６を備えている。

物理インタフェース２より入力された認証パケットはＥｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部３に到達する。Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部３に到達した認証パケットは、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダが解析される。具体的には、認証パケットの宛先ＭＡＣアドレスを抽出し、その宛先ＭＡＣアドレスが０１：８０：ｃ２：００：００：０３のマルチキャストアドレス、または、プロトコルがＥＡＰであるか否かを判定する。判定した結果、認証パケットの宛先ＭＡＣアドレスが０１：８０：ｃ２：００：００：０３のマルチキャストアドレス、または、プロトコルがＥＡＰである場合、認証パケットはインタフェース制御部４に渡される。

インタフェース制御部４は、予め設定されたフォワーディングポートに応じて、マルチキャストアドレスによる透過（経路１）、サプリカント又はＲａｄｉｕｓクライアントのＭＡＣアドレス、ブロードキャストアドレス（経路２）に書き換え、物理インタフェース７から再送信する。

一方で、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部３がＥＡＰ以外のパケットを受信すると、ネットワーク機器の保有するＭＡＣアドレステーブルに基づいて、当該パケットは転送（フォワーディング）される。

Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部３は、認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダを解析した結果に基づいて、認証パケットの透過または破棄の設定が可能である。認証パケットの透過または破棄の設定は、ネットワーク管理者やユーザによって変更可能である。

図２は、本発明のネットワーク機器の実施形態を説明するために使用する認証パケットのフォーマットを示す図である。
図２に示すように、認証パケットは、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダと認証データから構成される。Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダは、宛先ＭＡＣアドレス、送信元ＭＡＣアドレス、フレーム長で構成される。フレーム長には、このＥｔｈｅｒｎｅｔ（登録商標）パケットが認証パケットであることを示す値がセットされる。例えば、１がセットされていれば、認証パケットは、ＥＡＰ Ｒｅｑｕｅｓｔであり、２がセットされていれば、ＥＡＰ Ｒｅｓｐｏｎｓｅである。

認証パケットが透過されるか破棄されるかの設定は、ネットワーク管理者やユーザにより設定変更が可能である。仮に、認証パケットがネットワーク機器に到達した場合、ネットワーク管理者またはユーザが認証パケットを透過させる設定をしているのであれば、認証パケットはネットワーク機器内で破棄されることはなく、透過することになる。

一方で、認証パケットがネットワーク機器に到達した場合、ネットワーク管理者またはユーザが認証パケットを破棄させる設定をしているのであれば、認証パケットはネットワーク機器内で透過されることはなく、破棄することになる。

具体的な動作を図３を用いて詳細に説明する。

図３はＥｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部の動作を説明するフローチャートである。
図３に示すように、認証パケットはネットワーク機器のＥｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部に到着する（Ｓ１０１）。Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部は解析設定とされているか否かを判定する（Ｓ１０２）。Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部が解析設定とされている場合（Ｓ１０２：ＹＥＳ）、認証パケットから宛先ＭＡＣアドレス、上位プロトコルを抽出する（Ｓ１０３）。

続いて、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部は抽出した宛先ＭＡＣアドレスが０１：８０：ｃ２：００：００：０３のＥＡＰパケットであるか否かを判定する（Ｓ１０４）。抽出した宛先ＭＡＣアドレスが０１：８０：ｃ２：００：００：０３である場合（Ｓ１０４：ＹＥＳ）、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部は、予め管理者によって設定された処理、即ち、透過処理（Ｓ１０６１）、または宛先ＭＡＣアドレス書換再送信（Ｓ１０６２）を行い、転送（フォワーディング）処理を行う（Ｓ１０７）。また、抽出した宛先ＭＡＣアドレスが０１：８０：ｃ２：００：００：０３でない場合（Ｓ１０４：ＮＯ）、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部は、転送（フォワーディング）処理を行う（Ｓ１０７）。

一方、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部が解析設定とされていない場合（Ｓ１０１：ＮＯ）、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部は、宛先ＭＡＣアドレスが特定マルチキャストアドレスであるか否かを判定する（Ｓ１０８）。宛先ＭＡＣアドレスが特定マルチキャストアドレスである場合（Ｓ１０８：ＹＥＳ）、認証パケットは破棄される（Ｓ１０９）。宛先ＭＡＣアドレスが特定マルチキャストアドレスでない場合（Ｓ１０８：ＮＯ）、ＥＡＰ以外のパケットはネットワーク機器の保有するＭＡＣアドレステーブルに基づいて、当該パケットは転送（フォワーディング）される（Ｓ１０７）。

これらの機能は、セキュリティ性確保の観点から、デフォルト（初期設定）では破棄の設定とし、ネットワーク管理者やユーザにより設定変更が可能なことが望ましい。

続いて、本発明のＲａｄｉｕｓクライアントについて以下に詳細に説明する。

図４は、本発明のＲａｄｉｕｓクライアントを表したブロック図である。
図４に示すように、Ｒａｄｉｕｓクライアント８は、複数個の物理インタフェース１０−１から１０−ｎとネットワークプロセッサ９−１から９−ｎを備えている。それぞれのネットワークプロセッサ内には複数の認証インタフェース１１−１から１１−ｎが備えられている。Ｒａｄｉｕｓクライアント８は、物理インタフェース１０−１から１０−ｎ毎に複数の認証インタフェース１１−１から１１−ｎを実装する。認証インタフェース１１−１から１１−ｎは論理インタフェースで構成されている。なお、Ｒａｄｉｕｓクライアント８の認証インタフェース１１−１から１１−ｎは、ＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ：仮想ＬＡＮ）やサブインタフェース等であってもよい。

また、認証インタフェース１１−１から１１−ｎには、サプリカントのＭＡＣアドレスが登録されている。Ｒａｄｉｕｓクライアント８は、サプリカントからの認証応答パケットである“ＥＡＰ Ｒｅｓｐｏｎｓｅ”のＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報に含まれるサプリカントのＭＡＣアドレスを識別し、認証インタフェース１１−１から１１−ｎにバインド（連結）する。

その後、Ｒａｄｉｕｓクライアント８は、バインド（連結）された認証インタフェース１１−１から１１−ｎ上で、サプリカントの認証を行う。Ｒａｄｉｕｓクライアント８は、予め登録されているサプリカントのＭＡＣアドレスを使用し、認証要求パケットである“ＥＡＰ Ｒｅｑｕｅｓｔ”パケットをユニキャストで送信することが可能である。物理インタフェース１０−１から１０−ｎ毎の認証インタフェース１１−１から１１−ｎの数は、予め決められたサプリカントの数から、ネットワーク管理者によって設定可能とする。

図５は、本発明のＲａｄｉｕｓクライアントを表した他のブロック図である。
図５に示すように、Ｒａｄｉｕｓクライアント８は、複数個の物理インタフェース１０−１から１０−ｎとネットワークプロセッサ９−１から９−ｎを備えている。それぞれのネットワークプロセッサ内には認証アドレステーブル１２−１から１２−ｎが備えられている。Ｒａｄｉｕｓクライアント８は、物理インタフェース１０−１から１０−ｎ毎に認証アドレステーブル１２−１から１２−ｎを実装する。

図６は、図５に示す認証アドレステーブルを示す図である。
図６に示すように、認証アドレステーブルはＭＡＣアドレス、Ｔｙｐｅ、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｔａｔｅを備えたテーブルとなっている。ＴｙｐｅはＳｔａｔｉｃとＤｙｎａｍｉｃとからなる。Ｓｔａｔｉｃは管理者によって予め登録されたサプリカントのＭＡＣアドレスであり、ＤｙａｎａｍｉｃはサプリカントからのＥＡＰ、ＡＲＰ等のパケットから送信元ＭＡＣアドレスを登録する。この認証アドレステーブルに登録されたＭＡＣアドレスを使用し、Ｒａｄｉｕｓクライアントはサプリカントへユニキャストで認証パケットを送信する事が可能である。

また、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｔａｔｅは認証状態を表している。Ａｃｃｅｐｔは認証許可を表しており、Ｒｅｊｅｃｔは認証不許可を表している。即ち、認証が成功した場合は、認証アドレステーブルのＡｕｔｈｅｎｔｉｃａｔｉｏｎ ＳｔａｔｅにはＡｃｃｅｐｔが登録され、認証が失敗した場合、登録されたＭＡＣアドレスのサプリカントの認証が切れた場合、認証自体を行っていない場合は、認証アドレステーブルのＡｕｔｈｅｎｔｉｃａｔｉｏｎ ＳｔａｔｅにはＲｅｊｅｃｔが登録される。

図６に示す認証アドレステーブルは、サプリカントのＭＡＣアドレスをＳｔａｔｉｃに登録できる。その他、サプリカントから送信される認証応答パケットである“ＥＡＰ Ｒｅｓｐｏｎｓｅ”、やＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ：アドレス解決プロトコル）パケット等に含まれるサプリカントのＭＡＣアドレスをＤｙｎａｍｉｃに認証アドレステーブル１２−１から１２−ｎに登録が可能である。

ただし、このＤｙｎａｍｉｃにサプリカントＭＡＣアドレスの登録を可能とする指定プロトコルパケットの透過／破棄の設定は、ネットワーク管理者によって設定可能とする。

Ｒａｄｉｕｓクライアント８は、この認証アドレステーブル１２−１から１２−ｎを利用し、上位ネットワークへのアクセスを制御する。また、Ｒａｄｉｕｓクライアント８は、認証アドレステーブル１２−１から１２−ｎを利用し、サプリカントに対しユニキャストで、即ち単一の指定で、認証要求パケットである“ＥＡＰ Ｒｅｑｕｅｓｔ”を送信することが可能である。

物理インタフェース１０−１から１０−ｎ毎の認証アドレステーブル１２−１から１２−ｎの数は、予め決められたサプリカントの数から、ネットワーク管理者によって設定が可能である。

次に本発明のネットワーク機器及びＲａｄｉｕｓクライアントを備えた有線ＬＡＮ認証システムについて図７及び図８を参照して、認証フローの一例を詳細に説明する。

図７は、本発明の有線ＬＡＮ認証システムの概念図である。
図８は、本発明の実施の形態のＥｔｈｅｒｎｅｔ（登録商標）技術による有線ＬＡＮ認証システムの接続手順を示す図である。

図７及び図８に示すように、サプリカント１６−１が、ネットワーク機器１−２に接続すると、まず、ＩＥＥＥ８０２．１ｘの認証手順に基づき、Ｒａｄｉｕｓクライアント８は、宛先ＭＡＣアドレスが０１：８０：ｃ２：００：００：０３のＥＡＰ Ｒｅｑｕｅｓｔをネットワーク機器１−１宛に送信する（図８のＬ１）。宛先ＭＡＣアドレスが０１：８０：ｃ２：００：００：０３のＥＡＰ Ｒｅｑｕｅｓｔを受信したネットワーク機器１−１は、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析し、ネットワーク管理者の設定に応じてＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報の書き換えを行い、ネットワーク機器１−２宛に再送信する（図８のＬ２）。同時に、ＥＡＰ ＲｅｑｕｅｓｔパケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報に含まれるＲａｄｉｕｓクライアントのＭＡＣアドレス（送信元アドレス）を記憶する。

ネットワーク機器１−２は、図８のＬ２と同様の動作を行い、サプリカント１６−１宛に再送信する（図８のＬ３）。ネットワーク機器１−１において、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ情報が既にマルチキャスト以外のアドレスに書き換えられた場合には、ＥＡＰ Ｒｅｑｕｅｓｔはそのまま転送（フォワーディング）される。

サプリカント１６−１は、ＥＡＰ Ｒｅｑｕｅｓｔを受信すると、宛先ＭＡＣアドレスが０１：８０：ｃ２：００：００：０３のＥＡＰ Ｒｅｓｐｏｎｓｅをネットワーク機器１−２宛に送信する（図８のＬ４）。ネットワーク機器１−２は、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析し、ネットワーク管理者の設定に応じて、前記で記憶したＲａｄｉｕｓクライアントのＭＡＣアドレスにＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を書き換え、ネットワーク機器１−１宛に再送信する（図８のＬ５）。

ネットワーク機器１−１は、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析し、ネットワーク管理者の設定に応じて、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を書き換え、Ｒａｄｉｕｓクライアント８宛に再送信する（図８のＬ６）。ネットワーク機器１−２において、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ情報が既にマルチキャスト以外のアドレスに書き換えられた場合には、ＥＡＰ Ｒｅｓｐｏｎｓｅはそのまま転送（フォワーディング）される。

Ｒａｄｉｕｓクライアント８は、ＩＥＥＥ８０２．１ｘの認証手順に基づき、サプリカント１６−１からのＥＡＰパケットをＲａｄｉｕｓパケットにカプセル化し、Ｒａｄｉｕｓサーバ１４に送信する（図８のＬ７）。Ｒａｄｉｕｓサーバ１４は、認証のサプリカント１６−１に対し、認証に必要な情報（ユーザＩＤ、パスワード等）を要求する（図８のＬ８、Ｌ９）。

サプリカント１６−１は、宛先ＭＡＣアドレスが０１：８０：ｃ２：００：００：０３のＥＡＰ Ｒｅｓｐｏｎｓｅに認証情報（ユーザＩＤ、パスワード等）をセットし、ネットワーク機器１−２宛に送信する（図８のＬ１０）。ネットワーク機器１−２は、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析し、ネットワーク管理者の設定に応じて、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を書き換え、ネットワーク機器１−１宛に再送信する（図８のＬ１１）。

ネットワーク機器１−１は、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析し、ネットワーク管理者の設定に応じて、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を書き換え、Ｒａｄｉｕｓクライアント４８宛に再送信する（図８のＬ１２）。ネットワーク機器１−２において、Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ情報が既にマルチキャスト以外のアドレスに書き換えられた場合には、ＥＡＰ Ｒｅｓｐｏｎｓｅはそのまま転送（フォワーディング）される。

Ｒａｄｉｕｓクライアント８は、ＩＥＥＥ８０２．１ｘの認証手順に基づき、サプリカント−１からのＥＡＰパケットをＲａｄｉｕｓパケットにカプセル化し、Ｒａｄｉｕｓサーバ１４に送信する（図８のＬ１３）。Ｒａｄｉｕｓサーバ１４は、Ｒａｄｉｕｓパケットにセットされた認証情報（ユーザＩＤ、パスワード等）に基づき、認証の可否を行う。

Ｒａｄｉｕｓサーバ１４は、Ｒａｄｉｕｓサーバ１４自身に登録されている認証情報（ユーザＩＤ、パスワード等）と、Ｒａｄｉｕｓパケットにセットされた認証情報（ユーザＩＤ、パスワード等）を比較する。比較した結果、一致した場合、Ｒａｄｉｕｓサーバ１４は、Ｒａｄｉｕｓクライアント８宛に認証許可を示すＲａｄｉｕｓ Ａｃｃｅｐｔを送信する（図８のＬ１４）。一方で、一致しなかった場合、Ｒａｄｉｕｓサーバ１４は、Ｒａｄｉｕｓクライアント８宛に認証不許可を示すＲａｄｉｕｓ Ｒｅｊｅｃｔを送信する（図８のＬ１４）。

Ｒａｄｉｕｓクライアント８は、Ｒａｄｉｕｓサーバ４から送信されるＲａｄｉｕｓ ＡｃｃｅｐｔまたはＲａｄｉｕｓ Ｒｅｊｅｃｔのパケットを監視し、その中に含まれるサプリカントの情報（ＭＡＣアドレス、認証状況、サプリカントに許可された情報）等を認証テーブルに登録する。さらに、Ｒａｄｉｕｓクライアント８は、サプリカント１６−１に対して、認証の許可の場合、ＥＡＰ Ｓｕｃｃｅｓｓを、認証不許可の場合、ＥＡＰ Ｒｅｊｅｃｔを送信する（図８のＬ１５）。

なお、サプリカント１６−１からＥＡＰ以外の通信トラフィックをＲａｄｉｕｓクライアント８で受信した場合（図８のＬ１６、Ｌ１８）、サプリカント１６−１の認証状況によって、Ｒａｄｉｕｓクライアント８は所定の動作を行う。即ち、サプリカント１６−１の認証状況が不許可の場合、Ｒａｄｉｕｓクライアント８はサプリカント１６−１のトラフィックを破棄し、サプリカント１６−１に対してＲｅｊｅｃｔメッセージを送信する（図８のＬ１７）。

一方で、サプリカント１６−１の認証状況が許可の場合、Ｒａｄｉｕｓクライアント８はサプリカント１６−１のパケットにＲａｄｉｕｓクライアント８内部で、ＩＤ処理し、宛先に該当するインタフェースに転送（フォワーディング）する（図８のＬ１９）。

以上の説明においては、ネットワーク機器を制御するための制御プログラムが予めＲＯＭに記憶されている場合について説明したが、各種磁気ディスク、光ディスク、メモリカード等の記録媒体に制御用のプログラムをあらかじめ記録し、これらの記録媒体から読み込み、インストールするように構成することも可能である。

また、通信インタフェースを設け、インターネット、ＬＡＮなどのネットワークを介して制御用プログラムをダウンロードし、インストールして実行するように構成することも可能である。このように構成することにより、ソフトウェア的により高機能としたり、より信頼性の高いネットワーク機器を構成することが可能となる。

なお、本発明は、上述した実施形態に限定されるものではなく、その要旨を逸脱しない範囲内で種々変形して実施することが可能である。

本発明のネットワーク機器により、従来は廃棄されていたサプリカントからの認証パケットが、ネットワーク機器上で透過、廃棄の設定が可能となり、ＩＥＥＥ８０２．１ｘ認証技術の有線ＬＡＮネットワークの汎用性が広がるため、産業上の利用可能性が高い。

本発明のネットワーク機器のブロック図である。 認証パケットのフォーマットを示す図である。 Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部の動作を示すフローチャートである。 認証インタフェースを実装したＲａｄｉｕｓクライアントを示す概念図である。 認証アドレステーブルを実装したＲａｄｉｕｓクライアントを示す概念図である。 認証アドレステーブルを示す図である。 本発明のＩＥＥＥ８０２．１ｘ認証技術を利用した有線ＬＡＮ認証システムの構成を示す概念図である。 本発明の８０２．１ｘ認証技術を利用した有線ＬＡＮ認証システムの接続手順を示す図である。

符号の説明

１、１−１、１−２ ネットワーク機器
２、７、１０−１〜１０−ｎ 物理インタフェース
３ Ｅｔｈｅｒｎｅｔ（登録商標）ヘッダ解析部
４ インタフェース制御部
５ ＭＡＣアドレスデータベース
６ ヘッダ情報変換部
８ Ｒａｄｉｕｓクライアント
９−１〜９−ｎ ネットワークプロセッサ
１１−１〜１１−ｎ 認証インタフェース
１２−１〜１２−ｎ 認証アドレステーブル
１３ インターネット
１４ Ｒａｄｉｕｓサーバ
１５ 有線ＬＡＮ認証システム
１６−１、１６−２ サプリカント

Claims (20)

1. サプリカントとＲａｄｉｕｓクライアントとの間に備えられたネットワーク機器であって、前記Ｒａｄｉｕｓクライアントが接続される物理インタフェースと、前記Ｒａｄｉｕｓクライアントから送信される認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析する解析部と、解析した結果に基づいて、所定の動作を行う制御部とを備えたことを特徴とするネットワーク機器。
2. 前記解析部は、透過または破棄のいずれか１つの動作を行う手段を備えたことを特徴とする、請求項１に記載のネットワーク機器。
3. 前記制御部は、予め設定されたフォワーディングポートに応じて、前記認証パケットの宛先ＭＡＣアドレスをマルチキャストアドレス、サプリカント又はＲａｄｉｕｓクライアントのＭＡＣアドレス、ブロードキャストアドレスに書き換える手段を備えたことを特徴とする、請求項１または２のいずれか１項に記載のネットワーク機器。
4. 前記制御部は、前記認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報に含まれるサプリカントまたはＲａｄｉｕｓクライアントのＭＡＣアドレスを記憶し、各々のＭＡＣアドレス宛にユニキャストで送信する手段を備えたことを特徴とする、請求項１または２のいずれか１項に記載のネットワーク機器。
5. 有線ＬＡＮ認証システム用のＲａｄｉｕｓクライアントであって、物理インタフェースと、前記物理インタフェース毎に複数の認証インタフェースとが備えられたことを特徴とするＲａｄｉｕｓクライアント。
6. 前記認証インタフェースは論理インタフェースであることを特徴とする、請求項５に記載のＲａｄｉｕｓクライアント。
7. 前記認証インタフェースはＶＬＡＮであることを特徴とする、請求項５に記載のＲａｄｉｕｓクライアント。
8. 前記認証インタフェースはサブインタフェースであることを特徴とする、請求項５に記載のＲａｄｉｕｓクライアント。
9. 有線ＬＡＮ認証システム用のＲａｄｉｕｓクライアントであって、物理インタフェースと、前記物理インタフェース毎に認証アドレスを記憶する認証アドレス記憶手段とを備えたことを特徴とするＲａｄｉｕｓクライアント。
10. 複数のサプリカントに接続される請求項１に記載のネットワーク機器と、
    前記ネットワーク機器に接続される請求項５または９のいずれか１項に記載のＲａｄｉｕｓクライアントと、
    前記Ｒａｄｉｕｓクライアントに接続されるＲａｄｉｕｓサーバとが有線で接続され、さらにインターネットに接続される有線ＬＡＮ認証システム。
11. サプリカントとＲａｄｉｕｓクライアントとの間に備えられたネットワーク機器を認証パケットが透過する認証パケット透過方法であって、前記Ｒａｄｉｕｓクライアントが物理インタフェースに接続される接続ステップと、前記Ｒａｄｉｕｓクライアントから送信される認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析する解析ステップと、解析した結果に基づいて、所定の動作を行う制御ステップとを備えたことを特徴とする認証パケット透過方法。
12. 前記解析ステップは、前記認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析し、透過または破棄のいずれか１つの動作を行うステップを備えたことを特徴とする、請求項１１に記載の認証パケット透過方法。
13. 前記制御ステップは、予め設定されたフォワーディングポートに応じて、前記認証パケットの宛先ＭＡＣアドレスをマルチキャストアドレス、サプリカント又はＲａｄｉｕｓクライアントのＭＡＣアドレス、ブロードキャストアドレスに書き換える手段を備えたことを特徴とする、請求項１１または１２のいずれか１項に記載の認証パケット透過方法。
14. 前記制御ステップは、前記認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報に含まれるサプリカントまたはＲａｄｉｕｓクライアントのＭＡＣアドレスを記憶し、各々のＭＡＣアドレス宛にユニキャストで送信するステップを備えたことを特徴とする、請求項１１または１２のいずれか１項に記載の認証パケット透過方法。
15. サプリカントとＲａｄｉｕｓクライアントとの間に備えられたネットワーク機器に対し、ソフトウェア処理により認証パケットの透過を制御する制御プログラムであって、前記Ｒａｄｉｕｓクライアントを物理インタフェースに接続させ、前記Ｒａｄｉｕｓクライアントから送信される認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報を解析させ、前記解析した結果に基づいて、所定の動作を行わせることを特徴とする制御プログラム。
16. 前記解析は、透過または破棄のいずれか１つの動作を行わせることを特徴とする、請求項１５に記載の制御プログラム。
17. 前記制御は、予め設定されたフォワーディングポートに応じて、前記認証パケットの宛先ＭＡＣアドレスをマルチキャストアドレス、サプリカント又はＲａｄｉｕｓクライアントのＭＡＣアドレス、ブロードキャストアドレスに書き換えさせることを特徴とする、請求項１５または１６のいずれか１項に記載の制御プログラム。
18. 前記制御は、前記認証パケットのＥｔｈｅｒｎｅｔ（登録商標）ヘッダ情報に含まれるサプリカントまたはＲａｄｉｕｓクライアントのＭＡＣアドレスを記憶し、各々のＭＡＣアドレス宛にユニキャストで送信させることを特徴とする、請求項１５または１６のいずれか１項に記載の制御プログラム。
19. 請求項１５から請求項１８のいずれか１項に記載の制御プログラムを記録したことを特徴とするコンピュータ読取可能な記録媒体。
20. 認証パケット（ＥＡＰ Ｒｅｑｕｅｓｔ）に含まれるＲａｄｉｕｓクライアントのＭＡＣアドレスを記憶し、Ｒａｄｉｕｓクライアント宛にユニキャストで認証パケット（ＥＡＰ Ｒｅｓｐｏｎｓｅ）を送信するサプリカント。

Images