JPH10112709A - 認証方法 - Google Patents
認証方法Info
- Publication number
- JPH10112709A JPH10112709A JP34217996A JP34217996A JPH10112709A JP H10112709 A JPH10112709 A JP H10112709A JP 34217996 A JP34217996 A JP 34217996A JP 34217996 A JP34217996 A JP 34217996A JP H10112709 A JPH10112709 A JP H10112709A
- Authority
- JP
- Japan
- Prior art keywords
- interface
- nhrp
- authentication
- packet
- authentication key
- 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.)
- Granted
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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/10—Mapping addresses of different types
-
- 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/40—Network security protocols
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
イプを採用するLIS間および異なる管理ドメイン間で
のNHRPパケットの認証方法を提供する。 【解決手段】 NHSが、接続されている全てのLIS
の認証キーおよび認証タイプを獲得する。NHSが、あ
るLISからNHRPパケットを受信し、このパケット
を他のLISに転送する必要があると判断した場合、そ
のパケットを破棄する(ドロップモード)か、転送先の
LISの認証キーに付け替えてそのパケットを転送する
(フォワードモード)か、NHS自身のアドレス情報ま
たはIPパケットを転送できるその他のルータのアドレ
ス情報をリプライする(ゲートウェイモード)かのいず
れかの認証モードを、あらかじめ各NHSに設定できる
ようにしておく。この認証モードの設定は、どの入力イ
ンターフェイスからどの出力インターフェイスに転送す
るか毎に、どの認証モードを用いるかを設定できるよう
にする。各管理ドメインでは、ネットワーク管理者がど
の方針を採用するかを決めて、上記モードを選択し、設
定することができる。
Description
ークにおけるNHRPによるアドレス解決方法に関し、
特にNHRPパケットの認証の方法に関する。
ワークにおけるアドレス解決プロトコルとして、IET
F(Internet Engineering Ta
skForce)で議論されており、その仕様はdra
ft−ietf−rolc−nhrp−08.txt等
に記述されている。
ではNBMAネットワークとしてATMネットワーク
を、その上位プロトコルとしてはIP(Interne
t Protocol)を例に挙げて説明するが、これ
らが他のNBMAネットワークおよびネットワーク層プ
ロトコルであっても同様である。
ためには、通信相手のIPアドレスから、ATMアドレ
スを獲得する手段が必要となる。このため、NHRPプ
ロトコルでは、ATMネットワークに接続されているA
TM端末のIPアドレスおよびATMアドレスの対をあ
るエリア毎(例えば論理IPサブネット(LIS:Lo
gical IP Subnet)毎)に置かれたNH
RPサーバ(NHS)が分散管理する。
レスに対するATMアドレスを解決したい場合、あらか
じめ決められたNHSにNHRP Resolutio
nRequestパケットを送信する。NHRP Re
solution Requestパケットを受信した
NHSは、アドレスを解決できる場合にはNHRPRe
solution ReplyパケットをATM端末に
返送する。解決できない場合には、解決すべきIPアド
レスを管理していると思われる別のNHSの方向にその
NHRP Resolution Requestパケ
ットを転送する。すなわち、NHRP Resolut
ion Requestパケットは、アドレスを解決で
きるNHSに到着するまで、複数のNHS間を次々と転
送されて行く。
ている場合であっても、その通信相手がATMネットワ
ークに直接接続されている場合にはその通信相手自身の
ATMアドレスを解決することができる。通信相手がA
TMネットワークに直接接続されていない場合には、A
TMネットワークの中からの出口のルータ(ゲートウェ
イ)のATMアドレスを解決することができる。
RPパケットの拡張部(Extension par
t)に、Authentication Extens
ionを付加して行なうと規定されている。認証のタイ
プとして、「Keyed MD5」および「クリアテキ
ストパスワード」が規定されている(以下各々「MD
5」および「クリアテキスト」という)。NHRPパケ
ットの拡張部は必須ではないので、Authentic
ation Extensionを付加しない場合もあ
る。これを認証タイプ「なし」とすると、全部で3つの
異なる認証タイプが規定されていることになる。
ケットの種類に応じて、end−to−endに認証を
行なう(NHRP Registration Req
uestおよびNHRP Registration
Replyの時)か、またはhop−by−hopに認
証を行なう(それ以外のパケットの時)。
認証のタイプとして複数の異なるタイプが規定されてい
るにも関わらず、これらの異なる認証タイプの扱いが明
らかでない。このため、特にhop−by−hopの認
証の対象になるNHRPパケットが、あるLISから別
のLISに転送される場合、その2つのLIS間で認証
タイプが異なった場合の動作は実装に任せられることに
なる。
では、異なる認証タイプのLIS間ではNHRPパケッ
トを転送しないという方針をとりたいかもしれない。ま
た、ある別のネットワークの管理ドメインでは、異なる
認証タイプのLIS間でもNHRPパケットを転送して
も良いという方針をとりたいかもしれない。すなわち、
ネットワークの管理ドメイン毎に、異なる認証タイプの
LIS間でのNHRPパケットの扱いの方針を決定でき
ることが望ましい。
ダのNHRPサーバ間での認証に関する相互運用性が保
てなくなるという問題があった。つまり、上記のような
管理ドメイン毎の認証方針でNHRPを運用することが
できないという問題があった。
の複数の管理ドメイン間で、お互いに同一の認証タイプ
を用いるか異なる認証タイプを用いるかに関わらず、異
なる管理ドメイン間ではNHRPパケットを転送しない
という方針をとりたいことがあるかもしれない。逆に、
別の複数の管理ドメイン間では、お互いに同一の認証タ
イプを用いるか異なる認証タイプを用いるかに関わら
ず、異なる管理ドメイン間でもNHRPパケットを転送
しても良いという方針をとりたいかもしれない。すなわ
ち、ネットワークの管理ドメイン間では、NHRPパケ
ットの転送の扱いの方針を決定できることが望ましい。
な管理ドメイン間の認証方針でNHRPを運用すること
ができないという問題があった。
イプが異なった時のNHRPパケットの転送のモードお
よび管理ドメイン間でNHRPパケットの転送を行なう
時のモードを、管理ドメイン毎に設定できる方法を提供
することにある。
にすることにより、異なるベンダのNHS間でも相互運
用性が保てる方法を提供することにある。
ットワーク(NBMAネットワーク)における、ネット
ワーク層アドレスからデータリンク層アドレスへの変換
(アドレスを解決するという)を行なうNHRPプロト
コルにおいて、前記アドレス解決機能を提供するNHR
Pサーバがn個のサブネットワークに所属するためのn
個のインターフェイスを有している場合、前記NHRP
サーバが前記n個のインターフェイスに各々割り当てら
れている認証キーおよびそのタイプを保持する手段と、
前記NHRPサーバが、前記n個のインターフェイスの
うちあるインターフェイスからNHRPパケットを受け
とった場合、前記インターフェイスに割り当てられてい
る認証キーを用いて前記NHRPパケットの認証を行な
い、認証が不正の場合に前記NHRPパケットを破棄す
る手段を具備する。
Pパケットが前記インターフェイスに割り当てられてい
る認証キーで認証された場合で、前記インターフェイス
(第1のインターフェイス)から他のインターフェイス
(第2のインターフェイス)に前記NHRPパケットを
転送する必要がある場合において、前記第1のインター
フェイスに割り当てられている認証キーのタイプと前記
第2のインターフェイスに割り当てられている認証キー
のタイプが異なる場合、前記NHRPパケットを破棄す
る手段を具備する。
Pパケットが前記インターフェイスに割り当てられてい
る認証キーで認証された場合で、前記第1のインターフ
ェイスから前記第2のインターフェイスに転送する必要
がある場合において、前記第1のインターフェイスに割
り当てられている認証キーのタイプと前記第2のインタ
ーフェイスに割り当てられている認証キーのタイプが異
なる場合、前記NHRPパケットの認証キー部を前記第
2のインターフェイスに割り当てられている認証キーに
付け替えて、前記NHRPパケットを前記第2のインタ
ーフェイスから転送する手段を具備する。
Pパケットが前記インターフェイスに割り当てられてい
る認証キーで認証された場合で、前記第1のインターフ
ェイスから前記第2のインターフェイスに転送する必要
がある場合において、前記第1のインターフェイスに割
り当てられている認証キーのタイプと前記第2のインタ
ーフェイスに割り当てられている認証キーのタイプが異
なる場合、前記NHRPサーバの第1のインターフェイ
スのアドレス情報を返送する手段を具備する。
インターフェイスが属するサブネットワークと前記第2
のインターフェイスが属するサブネットワーク間でパケ
ットの転送を行なうルータの、前記第1のインターフェ
イスが属するサブネットワーク側のインターフェイスの
アドレス情報を用いる。
れている認証キーのタイプと前記第2のインターフェイ
スに割り当てられている認証キーのタイプに関わらず、
前記NHRPパケットを処理する。
を参照して説明する。
してATMネットワークを、その上位プロトコルをIP
として説明するが、これらが他のNBMAネットワーク
およびネットワーク層プロトコルであっても同様であ
る。
1上に複数のLIS(LIS−A10、LIS−B 2
0、LIS−C 30、LIS−D 40)が定義され
ているものとする。このATMネットワーク1に直接接
続されている端末(例えば端末11および端末41)は
お互いにATMレベルでSVC(SwitchedVi
rtual Connection)をセットアップす
ることができるものとする。なお、図1では、ATMネ
ットワークを構成するATMスイッチは省略してある。
また、これらを互いに接続する接続線等は一部を除き省
略してある。
およびNSH−C 300はNHRPサーバである。N
HS−A 100はLIS−A 10およびLIS−B
20に属するインターフェイスを持ち、NHS−B
200はLIS−B 20およびLIS−C 30に属
するインターフェイスを持ち、NHS−C 300はL
IS−C 30およびLIS−D 40に属するインタ
ーフェイスを持つ。
10を管理し、NHS−B 200はLIS−B 2
0を管理し、NHS−C 300はLIS−C 30お
よびLIS−D 40を管理するようにあらかじめ設定
されているものとする。
証タイプおよびそのキーをLIS毎に決める。例えばL
IS−A 10においては、MD5による認証を行な
い、MD5用のキーAを用いることとする。同様に、L
IS−B 20ではMD5による認証(キーB)、LI
S−C 30ではクリアテキストによる認証(キー
C)、LIS−D 40ではクリアテキストによる認証
(キーD)とする。
そのLIS毎に決められた認証キーおよびタイプを設定
する。例えば端末11にはキーAを設定する。なお、認
証キーの設定の仕方については任意の方法で良い。
イスを持っているので、各インターフェイス毎に認証キ
ーを設定する。図2にNHSのブロック図を示す。NH
RPサーバ処理部201はインターフェイス210、2
11、212を介してATMネットワークに接続されて
いる。図2において、認証キー記憶部202はNHRP
サーバ処理部201と接続され、各インターフェイス毎
の認証キーおよびそのタイプを設定する。
2に記憶された認証キーテーブルの一般的な構成を示
す。この認証キーテーブルには、インターフェイス番号
フィールド、認証キーフィールド、および認証タイプフ
ィールドから成るエントリが、そのNHSが持つインタ
ーフェイス分(210、211、212)だけ設定され
る。例えばNHS−B 200の認証キーテーブルの内
容は図4のようになる。
入力インターフェイスからどの出力インターフェイスへ
NHRPパケットを転送する場合にどの認証モード(ド
ロップモード、フォワードモード、ゲートウェイモード
のいずれか(後述))を用いるかを設定する。図5に、
図2における認証モード記憶部203に記憶された認証
モードテーブルの一般的な構成を示す。認証モードテー
ブルには、入力インターフェイス番号フィールド、出力
インターフェイス番号フィールド、認証モードから成る
エントリが、必要なだけ設定される。例えばNHS−B
200において、LIS−B 20からLIS−C
30へNHRPパケットを転送する必要がある場合はフ
ォワードモード、逆にLIS−C 30からLIS−B
20へNHRPパケットを転送する必要がある場合は
ドロップモードで運用したいとすると、NHS−B 2
00の認証モード記憶部の内容は図6のようになる。
方は任意の手段で良く、例えば各端末やNHS毎にファ
イルに記述する方法でも良いし、ネットワークを介して
設定する方法でも構わない。
4はIP層の働きをする。すなわち、インターフェイス
210、211、212を介してIPパケットが入力さ
れた場合、NHRPサーバ処理部201は何もせず、I
Pデータ転送部204がそのパケットを処理するものと
する。
ータ転送部204と接続されて、IPデータ転送部20
4があるインターフェイスから受信したIPパケットを
別のインターフェイスに転送する時に用いられる。更
に、IPルーティングテーブル205はNHRPサーバ
処理部201とも接続され、NHRPサーバ処理部20
1があるインターフェイスから受信したNHRPパケッ
トを別のインターフェイスに転送する時にも用いられ
る。
は、ネットワーク管理者により静的に設定されている
か、RIPまたはOSPFなどの既存のIPレベルのル
ーティングプロトコルを用いて動的に設定するものとす
る。
4およびIPルーティングテーブル205はNHSの内
部に存在しているように記述されているが、NHRPサ
ーバ処理部201とインターフェイス(210、21
1、212)が共用できるのであれば、必ずしもNHS
内に存在する必要はない。
明する。
41と通信しようとする場合を説明する。
esolution Request(認証タイプがM
D5なので、キーAを用いて送信するNHRPパケット
のMD5ダイジェストを計算し、これをAuthent
ication Extensionに入れる)をNH
S−A 100に送信する。
パケットに付加されているAuthenticatio
n Extensionと、このNHRPパケットを受
信したインターフェイスに割り当てられているキーAで
認証を行なう(認証タイプがMD5なので、Authe
ntication ExtensionからMD5ダ
イジェストを取り出し、NHS−A 100が持つキー
Aを用いてこのNHRPパケットのMD5ダイジェスト
を再度計算した結果と比較する)。端末11は正当なキ
ーAを持っていたので、このNHRPパケットは正当な
ものであると判断される。
を持った端末がNHS−A 100にNHRP Res
olution Requestを送信しても、不正な
NHRPパケットとして、エラー(NHRP Erro
r Indicationで、エラーコードがAuth
etication Failure)が送り返され、
当該NHRPパケットは破棄される。
不正にアクセスしようとした端末12を排除することが
できる。
イプがクリアテキストのLISにおいても同様である。
すなわち、端末11において、MD5ダイジェストをA
uthentication Extensionに入
れる代わりに、単にキーAそのもの(テキスト形式)を
Authentication Extensionに
入れる。また、NHS−A 100において、MD5ダ
イジェストを再度計算して比較する代わりに、単にキー
をAuthentication Extension
から取り出し、NHS−A 100の持つそれと比較す
る。
ストでも、Authentication Exten
sionを付加することを単に「キーを付加する」とい
うことにする。また、同様に、Authenticat
ion Extensionと、NHSの持つキーとで
認証を行なうことを単に「キーで認証する」ということ
にする。
する。
モード記憶部にはあらかじめ、入力インターフェイスか
ら出力インターフェイスへの転送の場合に「ドロップモ
ード」、「フォワードモード」、「ゲートウェイモー
ド」のいずれの認証モードを用いるかを設定しておく。
これにより、ある管理ドメインの境界に設置されている
NHSにおいて、用いられている認証タイプが上記管理
ドメイン内と管理ドメイン外で異なっている場合、上記
管理ドメインから外へNHRPパケットを転送すること
は許すが、上記管理ドメイン外からのNHRPパケット
は受け付けない、というような運用を可能にすることが
できる。
明する。
異なるLIS間でのNHRPパケットの転送を行なわな
い」という認証モードである。ドロップモードは本発明
で記述される認証モードのうち、最も強い認証を与え
る。
が異なるLIS間でもAuthentication
Extension内の認証キーを付け替えてNHRP
パケットの転送を継続して行なう」という認証モードで
ある。フォワードモードは本発明で記述される認証モー
ドのうち、最も弱い認証を与える。
が異なるLIS間のNHRP Resolution
Requestの場合は、NHSまたは他のルータのア
ドレス情報をリプライすることにより、送信端末からセ
ットアップされるSVCを一旦このNHSまたはルータ
で終端し、このNHSまたはルータのIP層に、受信す
るIPパケットの処理を任せるという、認証モードであ
る。ゲートウェイモードは本発明で記述される認証モー
ドのうち、ドロップモードより弱く、フォワードモード
より強い認証を与える。
トの処理の例を図7に示す。
段で良く、例えば各NHS毎にファイルに記述する方法
でも良いし、ネットワークを介して設定する方法でも構
わない。
00ではインターフェイス1から2へ転送の場合にはド
ロップモードを用いるように設定してあるものとする。
えば端末41のATMアドレスを解決するためのNHR
P Resolution Requestパケット)
がNHS−A 100からNHS−B 200に到着し
た場合を説明する。この場合、このNHRPパケットは
NHS−B 200では処理せず、NHS−C 300
へ転送される必要がある。
は、図8のフローチャートに従う。
の種類を判断する。NHRP Registratio
n RequestまたはNHRP Registra
tion Replyパケットであったら、ステップ5
02で、end−to−endの認証処理を行なう(従
来技術につき詳細省略)。
op−by−hopの認証を行なう。ステップ503
で、図2の認証キーテーブル202から認証キーおよび
タイプを取り出し、ステップ504で認証を行なう。こ
の結果、不正なNHRPパケットと判断されたら、ステ
ップ505でこのNHRPパケットを破棄し、このNH
RPパケットの送信者にエラーを送り返す。ここまでは
第1の実施の形態と同様である。
合、これをNHS−B 200自身が処理すべきか、そ
れとも他のNHSに転送する必要があるかどうかをステ
ップ506で判断する。端末41のアドレス情報はNH
S−B 200では管理されていないため、このNHR
PパケットはNHS−C 300に転送する必要がある
ので、ステップ508で、NHS−C 300に送信す
るためのインターフェイスに割り当てられている認証キ
ーおよびそのタイプを図2の認証キーテーブル202か
ら取り出す。
ンターフェイスの認証キーのタイプと、送信すべきイン
ターフェイスの認証キーのタイプが同じかどうか判断す
る。同じ場合はステップ510で、送信すべきインター
フェイスの認証キーに付け替えてNHRPパケットを送
信する。NHS−B 200では認証タイプが異なるの
で、ステップ511で図2の認証モード記憶部203か
ら、入力インターフェイス1から出力インターフェイス
2へ転送する際の認証モードを取り出す。
ターフェイス1から出力インターフェイス2へ転送する
際の認証モードはドロップモードと仮定する。そのた
め、ステップ512に進む。ステップ512で、このN
HRPパケットがNHRP Resolution R
equestパケットかどうかを判断する。NHRPR
esolution Requestパケットだった
ら、ステップ514で、Negative Reply
を返す。それ以外のパケットだったらステップ513
で、このNHRPパケットを破棄し、エラーを返す。
IS間でのNHRPパケットの転送を行なわないという
認証モード「ドロップモード」を実現できる。
する。
00の入力インターフェイス1から出力インターフェイ
ス2へ転送する際の認証モードはフォワードモードに設
定してあるものとする。
受信したとする。ステップ501からステップ511ま
では、第2の実施の形態と同様である。
00の入力インターフェイス1から出力インターフェイ
ス2へ転送する際の認証モードはフォワードモードであ
ると仮定すると、ステップ510に進む。ステップ51
0では、NHRPパケットのAutheticatio
n Extension内の認証キーを送信すべきイン
ターフェイスの認証キーに付け替えてNHRPパケット
を送信する。
IS間でもNHRPパケットの転送を継続して行なうと
いう認証モード「フォワードモード」を実現できる。
する。
00の入力インターフェイス1から出力インターフェイ
ス2へ転送する際の認証モードはゲートウェイモードに
設定してあるものとする。
とする。ステップ501からステップ511までは、第
2の実施の形態と同様である。
00の認証モードはゲートウェイモードであると仮定す
ると、ステップ515に進む。
がNHRP ResolutionRequestパケ
ットかどうかを判断する。NHRP Resoluti
on Requestパケットでなかったら、ステップ
519で、このNHRPパケットを破棄し、エラーを返
す。NHRP Resolution Request
であったら、ステップ516で、「解決すべきIPアド
レスがNHS−B200からIP reachable
か(IP的に到達可能か)どうか」をIPルーティング
テーブル205を参照して判断する。IP reach
ableでなかったら、ステップ518で、Negat
ive Replyを返す。IPreachableで
あったら、ステップ517で、このNHRPパケットを
受信したインターフェイスのアドレス情報をリプライす
る(Positive Reply)。
のリプライを受信すると、NHS−B 200までSV
Cをセットアップすることができる。この結果、送信端
末が送信したIPパケットは一旦、NHS−B 200
のIPデータ転送部204に到着することになる。この
IPパケットの扱いはNHS−B 200のIPデータ
転送部204に任せることとする。これにより、IPレ
ベルでのパケットフィルタリング等の機能を使うことが
できる(IPデータ転送部204の処理については本発
明の範囲外であるので省略する)。
IS間のNHRP Resolution Reque
stの場合は、NHSのアドレス情報をリプライするこ
とにより、送信端末からセットアップされるSVCを一
旦このNHSで終端し、このNHSのIPデータ転送部
に、受信するIPパケットの処理を任せるという、認証
モード「ゲートウェイモード」を実現できる。
する。
00の入力インターフェイス1から出力インターフェイ
ス2へ転送する際の認証モードはゲートウェイモードに
設定してあるものとする。また、NHS−B 200に
はルータ400のアドレス情報が設定されているものと
する。
受信したとする。ステップ501からステップ515ま
では、第4の実施の形態と同様である。
レスが、ルータ400からIP reachableか
どうか」を判断する。この判断の仕方は、例えば「ルー
タ400からLIS−D 40へはIP reacha
bleである」と静的に設定されている情報(ファイル
など)を元にしても良いし、NHS−B 200がルー
タ400とルーティングプロトコルによりIPルーティ
ング情報を交換している場合、その交換しているルーテ
ィング情報を元に行なっても良い。
は第1の実施の形態の場合と同様Negative R
eplyを返す。IP reachableであった
ら、ステップ517で、ルータ400のLIS−B 2
00側のインターフェイスのアドレス情報をリプライす
る(Positive Reply)。
のリプライを受信すると、ルータ400までSVCをセ
ットアップすることができる。この結果、送信端末が送
信したIPパケットは一旦、ルータ400のIP層に到
着することになる。このIPパケットの扱いはルータ4
00のIP層に任せることができる。これにより、IP
レベルでのパケットフィルタリング等の機能を使うこと
ができる(ルータ400のIP層の処理については本発
明の範囲外であるので省略する)。
IS間のNHRP Resolution Reque
stの場合は、他のルータのアドレス情報をリプライす
ることにより、送信端末からセットアップされるSVC
を一旦このルータで終端し、このルータのIP層に、受
信するIPパケットの処理を任せるという、認証モード
「ゲートウェイモード」を実現できる。
する。第6の実施の形態の動作は、第2の実施の形態か
ら第5の実施の形態の動作と基本的には同様である。但
し、入力インターフェイスおよび出力インターフェイス
に割り当てられている認証タイプに関わらず、設定され
ている認証モードに従ってNHRPパケットを処理す
る。例えば、NHS−B 200がNHRPパケットを
受信したとする。ステップ501からステップ508ま
では、第2の実施の形態から第5の実施の形態の場合と
同様である。
ンターフェイスの認証キーのタイプと、送信すべきイン
ターフェイスの認証キーのタイプが同じかどうか判断す
る処理をせず、そのままステップ511に進む。
部203から、入力インターフェイス1から出力インタ
ーフェイス2へ転送する際の認証モードを取り出す。以
降、この認証モードに従って第2の実施の形態から第5
の実施の形態の場合と同様に処理する。
る認証モードが設定されていない時は、例えば、フォワ
ードモードと同様の処理を行なう。
異なった時のNHRPパケットの転送のモードおよび管
理ドメイン間でNHRPパケットの転送を行なう時のモ
ードを、管理ドメイン毎に設定できることにある。
ルを持ち、これをネットワーク管理者が「ドロップモー
ド」、「フォワードモード」、「ゲートウェイモード」
のいずれかに設定することにより、各NHSがNHRP
パケットの転送時の認証の方法を変えるためである。
ベンダのNHS間でも相互運用性が保てることにある。
めの動作を明らかにしたためである。
Claims (6)
- 【請求項1】ATM(Asynchronous Tr
ansfer Mode)等のメディア共有型でないネ
ットワーク(NBMA:Non−Broadcast,
Multi−Access)におけるネットワーク層ア
ドレスを、データリンク層アドレスへ変換するアドレス
解決を行なうNHRPプロトコル(NHRP:Next
Hop Resolution Protocol)
におけるNHRPパケットの認証方法において、 前記アドレス解決を行なう機能を提供するNHRPサー
バがn個のサブネットワークに所属するためのn個のイ
ンタフェースを有している場合、前記NHRPサーバが
前記n個のインタフェースに各々割り当てられている認
証キーおよびそのタイプを保持し、 前記NHRPサーバが、前記n個のインタフェースのう
ちあるインタフェースからNHRPパケットを受けとっ
た場合、前記インタフェースに割り当てられている認証
キーを用いて前記NHRPパケットの認証を行ない、認
証が不正の場合に前記NHRPパケットを破棄すること
を特徴とするNHRPパケットの認証方法。 - 【請求項2】前記NHRPサーバが受信した前記NHR
Pパケットが前記インターフェイスに割り当てられてい
る認証キーで認証され、第1のインターフェイスから第
2のインターフェイスに前記NHRPパケットを転送す
る必要があり、前記第1のインターフェイスに割り当て
られている認証キーのタイプと前記第2のインターフェ
イスに割り当てられている認証キーのタイプが異なる場
合、前記NHRPパケットを破棄することを特徴とする
請求項1に記載のNHRPパケットの認証方法。 - 【請求項3】前記NHRPサーバが受信した前記NHR
Pパケットが前記インターフェイスに割り当てられてい
る認証キーで認証され、第1のインターフェイスから第
2のインターフェイスに転送する必要があり、前記第1
のインターフェイスに割り当てられている認証キーのタ
イプと前記第2のインターフェイスに割り当てられてい
る認証キーのタイプが異なる場合、前記NHRPパケッ
トの認証キー部を前記第2のインターフェイスに割り当
てられている認証キーに付け替えて、前記NHRPパケ
ットを前記第2のインターフェイスから転送することを
特徴とする請求項1に記載のNHRPパケットの認証方
法。 - 【請求項4】前記NHRPサーバが受信した前記NHR
Pパケットが前記インターフェイスに割り当てられてい
る認証キーで認証され、前記第1のインターフェイスか
ら前記第2のインターフェイスに転送する必要があり、
前記第1のインターフェイスに割り当てられている認証
キーのタイプと前記第2のインターフェイスに割り当て
られている認証キーのタイプが異なる場合、前記NHR
Pサーバの前記第1のインターフェイスのアドレス情報
を返送することを特徴とする請求項1に記載のNHRP
パケットの認証方法。 - 【請求項5】前記返送するアドレス情報として、 前記第1のインターフェイスが属するサブネットワーク
と前記第2のインターフェイスが属するサブネットワー
クとの間でパケットの転送を行なうルータの、前記第1
のインターフェイスが属するサブネットワーク側のイン
ターフェイスのアドレス情報を用いることを特徴とする
請求項4に記載のNHRPパケットの認証方法。 - 【請求項6】前記第1のインターフェイスに割り当てら
れている認証キーのタイプと前記第2のインターフェイ
スに割り当てられている認証キーのタイプが異なるか異
ならないかに関わらず、設定されている認証モードに従
って、前記NHRPパケットを処理することを特徴とす
る請求項2、3、4、5に記載のNHRPパケットの認
証方法。
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP34217996A JP2982727B2 (ja) | 1996-08-15 | 1996-12-20 | 認証方法 |
EP97113967A EP0825745B1 (en) | 1996-08-15 | 1997-08-13 | NHRP packet authentication method and NHRP server |
DE69735915T DE69735915T2 (de) | 1996-08-15 | 1997-08-13 | NHRP-Paketauthentifizierungsverfahren und NHRP-Server |
US08/910,170 US6009102A (en) | 1996-08-15 | 1997-08-13 | NHRP packet authentication method and NHRP server |
CA002213045A CA2213045C (en) | 1996-08-15 | 1997-08-14 | Nhrp packet authentication method and nhrp server |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP21574696 | 1996-08-15 | ||
JP8-215746 | 1996-08-15 | ||
JP34217996A JP2982727B2 (ja) | 1996-08-15 | 1996-12-20 | 認証方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH10112709A true JPH10112709A (ja) | 1998-04-28 |
JP2982727B2 JP2982727B2 (ja) | 1999-11-29 |
Family
ID=26521031
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP34217996A Expired - Fee Related JP2982727B2 (ja) | 1996-08-15 | 1996-12-20 | 認証方法 |
Country Status (5)
Country | Link |
---|---|
US (1) | US6009102A (ja) |
EP (1) | EP0825745B1 (ja) |
JP (1) | JP2982727B2 (ja) |
CA (1) | CA2213045C (ja) |
DE (1) | DE69735915T2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2003509970A (ja) * | 1999-09-16 | 2003-03-11 | ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー | パケット認証 |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3094937B2 (ja) * | 1997-03-28 | 2000-10-03 | 日本電気株式会社 | Atm論理ipサブネットワークの障害復旧方式 |
FI105753B (fi) * | 1997-12-31 | 2000-09-29 | Ssh Comm Security Oy | Pakettien autentisointimenetelmä verkko-osoitemuutosten ja protokollamuunnosten läsnäollessa |
US6252857B1 (en) * | 1998-03-04 | 2001-06-26 | At&T Corp. | Method and apparatus for provisioned and dynamic quality of service in a communications network |
US7143193B1 (en) | 1998-05-29 | 2006-11-28 | Yahoo! Inc. | Content collection |
US7581006B1 (en) * | 1998-05-29 | 2009-08-25 | Yahoo! Inc. | Web service |
US6976093B2 (en) | 1998-05-29 | 2005-12-13 | Yahoo! Inc. | Web server content replication |
JP4080599B2 (ja) * | 1998-06-17 | 2008-04-23 | 富士通株式会社 | 通信制御装置およびマルチキャスト対応lanに適用される通信制御方法 |
EP1108320A1 (en) | 1998-08-26 | 2001-06-20 | Nortel Networks Limited | NON-BROADCAST, MULTIPLE ACCESS INVERSE NEXT HOP RESOLUTION PROTOCOL (InNHRP) |
JP2000295274A (ja) * | 1999-04-05 | 2000-10-20 | Nec Corp | パケット交換装置 |
US6226752B1 (en) * | 1999-05-11 | 2001-05-01 | Sun Microsystems, Inc. | Method and apparatus for authenticating users |
US6898200B1 (en) * | 1999-10-29 | 2005-05-24 | Nortel Networks Limited | Method for improving signaling efficiency and performing service load balancing in a connection oriented network |
CN1297104C (zh) * | 2002-12-04 | 2007-01-24 | 华为技术有限公司 | 实现基于端口认证和基于传输层认证兼容的方法 |
JP4174392B2 (ja) * | 2003-08-28 | 2008-10-29 | 日本電気株式会社 | ネットワークへの不正接続防止システム、及びネットワークへの不正接続防止装置 |
US7716406B1 (en) * | 2005-03-02 | 2010-05-11 | Crossroads Systems, Inc. | Method and system for persistent reservation handling in a multi-initiator environment |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5600644A (en) * | 1995-03-10 | 1997-02-04 | At&T | Method and apparatus for interconnecting LANs |
US5583862A (en) * | 1995-03-28 | 1996-12-10 | Bay Networks, Inc. | Method and apparatus for routing for virtual networks |
US5617540A (en) * | 1995-07-31 | 1997-04-01 | At&T | System for binding host name of servers and address of available server in cache within client and for clearing cache prior to client establishes connection |
US5699347A (en) * | 1995-11-17 | 1997-12-16 | Bay Networks, Inc. | Method and apparatus for routing packets in networks having connection-oriented subnetworks |
JP2728064B2 (ja) * | 1995-11-20 | 1998-03-18 | 日本電気株式会社 | アドレス解決方法 |
US5809233A (en) * | 1995-12-05 | 1998-09-15 | Lucent Technologies Inc. | Method of mapping from ATMARP to NHRP |
US5828844A (en) * | 1996-10-08 | 1998-10-27 | At&T Corp. | Internet NCP over ATM |
-
1996
- 1996-12-20 JP JP34217996A patent/JP2982727B2/ja not_active Expired - Fee Related
-
1997
- 1997-08-13 EP EP97113967A patent/EP0825745B1/en not_active Expired - Lifetime
- 1997-08-13 DE DE69735915T patent/DE69735915T2/de not_active Expired - Lifetime
- 1997-08-13 US US08/910,170 patent/US6009102A/en not_active Expired - Lifetime
- 1997-08-14 CA CA002213045A patent/CA2213045C/en not_active Expired - Fee Related
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2003509970A (ja) * | 1999-09-16 | 2003-03-11 | ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー | パケット認証 |
Also Published As
Publication number | Publication date |
---|---|
EP0825745B1 (en) | 2006-05-24 |
DE69735915T2 (de) | 2007-01-18 |
EP0825745A3 (en) | 2003-10-08 |
JP2982727B2 (ja) | 1999-11-29 |
DE69735915D1 (de) | 2006-06-29 |
CA2213045C (en) | 2000-11-28 |
US6009102A (en) | 1999-12-28 |
CA2213045A1 (en) | 1998-02-15 |
EP0825745A2 (en) | 1998-02-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11283772B2 (en) | Method and system for sending a message through a secure connection | |
Luciani et al. | NBMA next hop resolution protocol (NHRP) | |
FI118619B (fi) | Menetelmä ja järjestelmä tiedon salaamiseksi ja tallentamiseksi | |
JP2728064B2 (ja) | アドレス解決方法 | |
US6915345B1 (en) | AAA broker specification and protocol | |
JP2982727B2 (ja) | 認証方法 | |
JPH09252323A (ja) | 通信システムおよび通信装置 | |
US20090151009A1 (en) | Systems and methods for end-to-end resource reservation authentication | |
US20070036110A1 (en) | Access control of mobile equipment to an IP communication network with dynamic modification of the access policies | |
JP3009876B2 (ja) | パケット転送方法および該方法に用いる基地局 | |
WO2002082769A2 (en) | Facilitating legal interception of ip connections | |
Richardson et al. | Opportunistic encryption using the internet key exchange (ike) | |
Eronen et al. | IKEv2 clarifications and implementation guidelines | |
US6347338B1 (en) | Precomputed and distributed security system for a communication network | |
JP2845207B2 (ja) | アドレス解決装置 | |
US7895648B1 (en) | Reliably continuing a secure connection when the address of a machine at one end of the connection changes | |
US10841283B2 (en) | Smart sender anonymization in identity enabled networks | |
Luciani et al. | RFC2332: NBMA Next Hop Resolution Protocol (NHRP) | |
Eronen et al. | RFC 4718: IKEv2 clarifications and implementation guidelines | |
Tsaur et al. | Establishing secure Ethernet LANs using intelligent switching hubs in Internet environments | |
Piscitello et al. | Network Working Group J. Luciani Request for Comments: 2332 Bay Networks Category: Standards Track D. Katz cisco Systems | |
JPH118627A (ja) | 認証機能を有する交換機 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 19990824 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080924 Year of fee payment: 9 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080924 Year of fee payment: 9 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090924 Year of fee payment: 10 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090924 Year of fee payment: 10 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100924 Year of fee payment: 11 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110924 Year of fee payment: 12 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120924 Year of fee payment: 13 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130924 Year of fee payment: 14 |
|
LAPS | Cancellation because of no payment of annual fees |