JP3457645B2 - ネットワーク・アドレス変換とプロトコル変換が存在する場合のパケット認証の方法 - Google Patents

ネットワーク・アドレス変換とプロトコル変換が存在する場合のパケット認証の方法

Info

Publication number
JP3457645B2
JP3457645B2 JP2000528056A JP2000528056A JP3457645B2 JP 3457645 B2 JP3457645 B2 JP 3457645B2 JP 2000528056 A JP2000528056 A JP 2000528056A JP 2000528056 A JP2000528056 A JP 2000528056A JP 3457645 B2 JP3457645 B2 JP 3457645B2
Authority
JP
Japan
Prior art keywords
packet
node
translation
receiving node
network device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2000528056A
Other languages
English (en)
Other versions
JP2002501332A (ja
Inventor
イローネン，タツ
Original Assignee
アスアスホー コミュニケーションズ セキュリティ オサケユイチア
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by アスアスホー コミュニケーションズ セキュリティ オサケユイチア filed Critical アスアスホー コミュニケーションズ セキュリティ オサケユイチア
Publication of JP2002501332A publication Critical patent/JP2002501332A/ja
Application granted granted Critical
Publication of JP3457645B2 publication Critical patent/JP3457645B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

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/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2564—NAT traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]
    • 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/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
    • 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/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2578—NAT traversal without involvement of the NAT server
    • 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/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2585—NAT traversal through application level gateway [ALG]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • 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
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

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)

Description

【発明の詳細な説明】
【０００１】本発明は、デジタル・データ転送ネットワ
ークにおけるデータ・パケットの認証に関する。特に、
本発明は、転送中のパケットに対して変換が行われ、従
来技術の認証方法の使用を困難または不可能にするネッ
トワークにおける認証に関する。
【０００２】インターネットが大きく成長し、ネットワ
ークに参加する組織の数が急速に増加したため、近年イ
ンターネット・セキュリティは重要な科学的及び商業的
注目を浴びている。ネットワークは多くの営利団体の業
務の重要な一部分になった。インターネットの商業的利
用は、既存のインターネット・プロトコルにおけるセキ
ュリティの問題によって大きく制限されており、インタ
ーネット・セキュリティの改善が不可欠である。
【０００３】ＩＰセキュリティ・プロトコル（ＩＰＳＥ
Ｃ）は、ＩＰプロトコルにセキュリティを追加してＩＥ
ＴＦ（インターネット技術標準化委員会）によって標準
化されている。これは２つの通信中のネットワーク・ノ
ード間の暗号化認証とトラフィックの機密性を提供す
る。これは、通信中のノードまたはホスト間直接の終端
間モード、またはファイアウォールまたはＶＰＮ（バー
チャル私設ネットワーク）装置間のトンネル・モードの
両方で使用できる。一端がホストでもう一端がファイア
ウォールまたはＶＰＮである非対称接続も可能である。
【０００４】ＩＰＳＥＣは各パケットに新しいプロトコ
ル・ヘッダを追加することでパケット・レベルでの認証
と暗号化を行い、ＩＰＳＥＣの認証は、データ・パケッ
トの全てのデータとヘッダの大部分について認証コード
を計算することで行われる。認証コードはさらに、通信
中の当事者だけに知られた秘密キーに依存する。認証コ
ードは、明確なヘッダまたはトレーラ（trailer ）に適
切にラップ（wrap）され、パケットに保存される。
【０００５】認証用の秘密キーは、通信中のホストの各
対に対して手動で設定できる。しかし、実際には、専用
キー管理プロトコルが使用され、秘密キーを動的に生成
及び交換する。ＩＰＳＥＣでは、これを行うための標準
プロトコルはＩＳＡＫＭＰ／Ｏａｋｌｅｙプロトコルと
呼ばれるが、ＩＳＡＫＭＰとはインターネット・セキュ
リティ・アソシエーション・キー管理プロトコル（Inte
rnet Security Association Key Management Protocol
）の意味である。
【０００６】ＩＰＳＥＣ認証保護にはパケットの送信元
及び宛先のアドレスが含まれるが、これは、認証コード
を有効なままにする場合転送中のアドレスを変更できな
いということを意味する。しかし、多くの組織は現在自
組織内の私用ＩＰアドレスを使用し、外部ゲートウェイ
（例えば、ルータまたはファイアウォール）で私用アド
レスをグローバルに一意なアドレスに変換している。こ
の処理はネットワーク・アドレス変換（ＮＡＴ）と呼ば
れる。この変換は典型的には、ＩＰアドレス及びＴＣＰ
またはＵＤＰポート番号両方の変更を伴う。
【０００７】図１のＮＡＴ装置１００は、内部私設ネッ
トワーク１０３内の送信ノード１０２によって送信され
たパケット１０１を取り入れる。これは、外部ネットワ
ーク１０５を通じて受信ノード１０６にパケットを送信
する前に、パケットのＩＰアドレスとポート番号を、内
部私用アドレス空間に属するものから、送出パケット１
０４のグローバルに一意な外部インターネット・アドレ
スに変換する。アドレス変換は他の方向にＮＡＴ装置１
００を通過するパケットについては逆に行われる。典型
的には、ＮＡＴ１００はＩＰアドレスとポートの組合せ
を別のＩＰアドレスとポートの組合せにマッピングす
る。マッピングはネットワーク接続の持続期間を通じて
一定であるが、時間と共に（ゆっくりと）変更されるこ
とがある。実際にはＮＡＴの機能性はファイアウォール
またはルータに統合されることが多い。
【０００８】さらに、送信される際パケットを正当に修
正するインターネット上の他の種類の装置が存在する。
代表的な例はプロトコル変換器であるが、その主要な仕
事は、正常な動作を妨げることなくパケットを別のプロ
トコルに変換することである。こうした装置を使用する
ことはＮＡＴの場合と非常によく似た問題につながる。
プロトコル変換器はパケットをあるプロトコルから別の
プロトコルに変換する。ごく簡単だが重要な例は、イン
ターネット・プロトコルの異ったバージョンであるＩＰ
ｖ４とＩＰｖ６間の変換である。このような変換器は近
い将来極めて重要で一般的になるだろう。パケットは移
動中この種のいくつかの変換を受けて、通信の端点が実
際には別のプロトコルを使用しているということがあり
うる。ＮＡＴと同様、プロトコル変換がルータ及びファ
イアウォールで行われることが多い。ＩＰｖ４パケット
・ヘッダのレイアウトは図２に図示され、ＩＰｖ６パケ
ット・ヘッダのレイアウトは図３に図示されている。図
２及び図３の列番号はビットに対応する。
【０００９】図２では、周知のＩＰｖ４ヘッダのフィー
ルドは、バージョン番号２０１、ＩＨＬ２０２、サービ
ス種別２０３、合計長２０４、識別番号２０５、フラグ
２０６、フラグメント・オフセット２０７、タイム・ト
ウー・リブ（Time to Live）２０８、プロトコル２０
９、ヘッダ・チェックサム２１０、送信元アドレス２１
１、宛先アドレス２１２、オプション２１３及びパディ
ング２１４である。図３では、提案中の周知のＩＰｖ６
ヘッダのフィールドは、バージョン番号３０１、トラフ
ィック・クラス３０２、フロー・ラベル３０３、ペイロ
ード長３０４、ネクスト・ヘッダ３０５、ホップ・リミ
ット３０６、送信元アドレス３０７及び宛先アドレス３
０８である。ヘッダでのフィールドの用法は当業者にと
っては周知である。ＩＰパケットは、データ部分を伴う
図２または図３のもののようなヘッダからなる。ＩＰｖ
６では、図３に示される主ヘッダとデータ部分の間に多
数のいわゆる拡張ヘッダが存在することがある。
【００１０】ネットワーク・セキュリティ・プロトコル
の望ましいセキュリティ特性には、認証性（authentici
ty）（パケットは送信元となるよう要求されたノードに
よって実際に送信されている）、整合性（integrity ）
（パケットは転送中に修正されていない）、非否認性
（non-repudiation ）（送信ノードはパケットを送信し
たことを否定できない）及びプライバシ（第三者はパケ
ットのコンテンツを読むことができない）が含まれる。
ＩＰＳＥＣプロトコルでは、各パケットを認証するため
に使用される共有秘密キーを有することで、認証性、整
合性及び非否認性が達成される。認証は、パケット及び
共有秘密キーのコンテンツを使用してメッセージ認証コ
ード（ＭＡＣ）を計算し、計算されたＭＡＣをＡＨ（認
証ヘッダ）またはＥＳＰ（カプセル化セキュリティ・ペ
イロード）ヘッダでパケットの一部として送信すること
で行われる。プライバシは典型的には暗号化を使用して
実現され、ＥＳＰヘッダが使用される。ＡＨヘッダは図
４に図示されるが、そこでは列番号はビットに対応す
る。周知のＡＨヘッダのフィールドは、ネクスト・ヘッ
ダ４０１、長さ４０２、予備４０３、セキュリティ・パ
ラメータ４０４及び認証データ４０５である。最後のフ
ィールド４０５の長さは３２ビット語の変数である。
【００１１】カプセル化セキュリティ・ペイロード（Ｅ
ＳＰ）は、ＩＰヘッダの後で、かつ最終トランスポート
層プロトコルの前のＩＰパケットのどこにでも現れてよ
い。インターネット・アドレス管理機構（Internet Asi
gned Numbers Authority）はプロトコル番号５０をＥＳ
Ｐに割り当てている。ＥＳＰヘッダの直前のヘッダは常
にそのネクスト・ヘッダ（ＩＰｖ６）またはプロトコル
（ＩＰｖ４）フィールドに値５０を含んでいる。ＥＳＰ
は非暗号化ヘッダとそれに続く暗号化データからなる。
暗号化データには、保護ＥＳＰヘッダ・フィールドと、
ＩＰデータグラム全体であるかまたは上位層プロトコル
・フレーム（例えば、ＴＣＰまたはＵＤＰ）である保護
ユーザ・データの両方が含まれる。高安全性ＩＰデータ
グラムの高レベル図が図５ａに図示されるが、そこでは
フィールドは、ＩＰヘッダ５０１、オプションの他のＩ
Ｐヘッダ５０２、ＥＳＰヘッダ５０３及び暗号化データ
５０４である。図５ｂは３２ビット・セキュリティ・ア
ソシエーション識別子（ＳＰＩ）（Security Associati
on Identifier ）５０５と、可変長であるオペーク・ト
ランスフォーム・データ（Opaque Transfom Data）５０
６という、ＥＳＰヘッダの２つの部分を図示する。
【００１２】ＭＡＣを計算するには、文献で周知のいく
つかの方法がある。１つの一般的に使用される方法は、
キーとして共有秘密キーを使用して、認証すべきデータ
についてキー付き暗号化ハッシュ関数（例えば、ＨＭＡ
Ｃ−ＳＨＡ１）を計算することである。ここではパケッ
トの認証、整合性、及び非否認性を合わせてパケット認
証と呼ぶ。ＩＰＳＥＣでは、この機能は、送信ノードで
パケットについてメッセージ認証コード（ＭＡＣ）を計
算し、パケットで計算されたメッセージ認証コードをＡ
ＨまたはＥＳＰヘッダに収容し、受信ノードでメッセー
ジ認証コードを検証することで達成される。両方のノー
ドが同じ共有秘密を知っており、受信されたパケットが
ＭＡＣが計算された元のパケットと同一である場合、検
証は成功する。
【００１３】ＮＡＴとプロトコル変換器はそれらの性質
自体によって、転送する際パケットを修正する。しか
し、パケット認証の本来の目的はパケットの修正を防止
することであり、パケットの変形（transformation）が
あると、認証は失敗することになる。ＮＡＴはパケット
の送信元及び／または宛先アドレスを変更するので、Ｉ
ＰＳＥＣ認証コードは無効になる。認証コードにアドレ
スを含めない、隣接ＮＡＴゲートウェイの各対の間で認
証を行う、またはＩＰ内ＩＰカプセル化でパケットをラ
ップする等、こうした環境で認証を行ういくつかの解決
法が提案されている。しかし、未知の数の中間ＮＡＴゲ
ートウェイが存在する時、複雑なディレクトリや手動設
定、またはパケットを修正する各ゲートウェイの再認証
を必要とせずにエンドツーエンド（end-to-end）認証を
可能にする解決法は知られていない。
【００１４】ＥＳＰ認証方法は計算されたＭＡＣにパケ
ット・ヘッダを含めない。この本来の目標はＮＡＴを越
えてＥＳＰを働かせることであった。しかし、このアプ
ローチには重大な問題が存在する。第１に、ＴＣＰ／Ｉ
Ｐヘッダはチェックサムを収容するが、これには、実際
のＴＣＰペイロードに加えて、パケットのネットワーク
・アドレスとポート番号を含む疑似ヘッダが含まれる。
すなわち、ＮＡＴが行われる時ＴＣＰ／ＩＰチェックサ
ムは変化する。通常ＮＡＴ装置は自動的にチェックサム
を訂正するが、セキュリティ・プロトコルを使用してパ
ケットが保護されている時これは不可能である。ＵＤＰ
プロトコルの場合も同じ状況が生じる。すなわち、既存
の方法ではＥＳＰを通じてさえＴＣＰ及びＵＤＰを確実
に使用することはできない。
【００１５】データ・パケットを修正する技術を使用す
る方向にベンダと企業を向かわせる強い力が存在する。
それはＩＰｖ４アドレス空間が枯渇しつつあることであ
る。すなわち、企業はもはや妥当なコストで十分な数の
ＩＰアドレスを得ることができない。企業を同じ方向に
向かわせるもう１つの力は、ＩＰアドレスを付け替える
ことは非常に費用がかかり、別のインターネット・サー
ビス・プロバイダに変更する場合外部番号を変更する必
要がありうるということである。
【００１６】こうした力は、インターネットを２つの可
能な代替解決法、すなわちＮＡＴの使用を増大するか、
またはＩＰｖ６に移行する（プロトコル変換が一般的に
なるまでの長い移行期間を当然伴う）という方向に向か
わせている。現在のＩＰＳＥＣプロトコルは、柔軟性ま
たはセキュリティの点で大きく妥協することなくこれら
の解決法の何れかに対処することはできない。
【００１７】パケット転送中のアドレス変換とプロトコ
ル変換の影響を受けないパケット認証の方法を提供する
ことが本発明の目的である。前記方法を利用することの
できる送信ネットワーク装置と受信ネットワーク装置を
提供することが本発明のさらに別の目的である。本発明
の目的は、まず通信中のホスト間のパケットに対して行
われるアドレス変換及び／またはプロトコル変換を動的
に発見し、パケット認証コードが計算または検証される
時こうした変化を補償することによって達成される。
【００１８】本発明による方法の特徴は、送信ノードと
受信ノードの間を転送中のパケットに対して行われる変
換を動的に発見するステップと、適用可能なセキュリテ
ィ・ポリシーに基づいて、発見された変換が許容可能か
を検査するステップと、送信ノードから受信ノードに送
信されるパケットを認証する前に動的に発見された、許
容可能な変換を補償するステップと、を含んでいること
である。
【００１９】本発明はまた、前記方法を利用する能力を
その特性の特徴とするネットワーク装置にも適用され
る。本発明の第１部分は、パケットを認証する必要のあ
る通信に参加するネットワーク装置またはノードが、プ
ローブ（probe ）を交換し、受信プローブの情報を送信
の時点の既知の形態として比較することで、ネットワー
ク経路のネットワーク・アドレス変換及び／またはプロ
トコル変換特性を動的に発見することにある。
【００２０】本発明の第２部分は、ネットワーク経路の
ネットワーク・アドレス変換及び／またはプロトコル変
換特性を動的に発見した後、送信ノード及び／または受
信ノードがパケットに対して行われた全てのアドレス変
換及び／またはプロトコル変換を補償し、アドレス変換
及び／またはプロトコル変換が存在する時でもパケット
認証が安全に達成されるようにすることにある。
【００２１】本発明の特徴とみなされる新しい特徴は、
特に添付の請求項に示される。しかし、本発明自体は、
その構成及び動作方法の両方に関して、その付加的な目
的及び利点と共に、個々の実施形態の以下の説明を添付
の図面と共に読む時そこから最もよく理解される。図１
〜図５ｂは従来技術の説明の中で参照されたので、以下
の議論は主として図６〜図１３に関する。
【００２２】本発明は、ＩＰプロトコル及びＩＰＳＥＣ
及びＩＳＡＫＭＰ／Ｏａｋｌｅｙ機構の文脈で説明され
る。しかし、本発明は、以下の説明の特定プロトコル及
び機構用の名称及び仕様を他のネットワーク・プロトコ
ル及び他のセキュリティ機構の対応する相当物に置き換
えることで、他のネットワーク・プロトコル及び他のセ
キュリティ機構に等しく適用可能である。
【００２３】本発明は、転送中にパケットを修正するＮ
ＡＴ（ネットワーク・アドレス変換）装置及び／または
プロトコル変換器が存在する時パケット認証を行う方法
に関する。本発明はまた、あるＩＰオプション（例えば
送信元ルーティング）を除去する、またはセキュリティ
・オプション（例えばＩＰＳＯまたはＣＩＰＳＯ）を追
加するといった、パケットに対して行われる多くの他の
種類の変換にも等しく適用可能である。
【００２４】本発明は、送信ノードで認証コードを生成
する前か、または受信ノードでそれを検証した後の何れ
かでアドレス変換及び／またはプロトコル変換を補償す
ることにより、それらに対する認証を働かせることが可
能であるという事実に基づいている。しかし、こうした
補償には、通信中のピア（communicating peer）間でパ
ケットに対して行われる正確な変換を知ることが必要で
ある。多くの変換は時間に依存する。例えば、ＮＡＴに
よって与えられる外部アドレスは先着順方式で時間と共
に変化することがある。変換が一定である場合でも、可
能な通信ノードの対毎に変換情報を静的な方法で設定及
び維持することは極めて厄介である。
【００２５】本発明による方法では、通信が行われる時
点である特定のネットワーク接続に対してどんな変換が
行われるかを動的に発見し、パケット認証を行う際その
変換を補償する。すなわち、問題は、いかにして確実か
つ安全に発見するか、発見されたどの変換が許容可能と
みなされるか、及びパケットの転送中に発生する変換を
いかに補償するか、といった多数の下位問題に分割され
る。
【００２６】通信中のノード間の経路の変換特性は十分
に小さな細分性を持って決定しなければならない。ここ
で十分に小さな細分性とはネットワーク・アドレスの範
囲（例えば、ＩＰサブネット、個別ＩＰアドレス、また
さらにポート番号）を指す。例えば、多くのＮＡＴはＩ
Ｐアドレスとポートの組合せを別のＩＰアドレスとポー
トの組合せにマッピングする。このような場合、細分性
はポートに関する。他方、別の環境では同じ一定の変換
がＩＰサブネット全体またはサブネットの集合に適用さ
れることがある。この実現は、変換特性が常に各「グラ
ニュール（granule ）」について個別に決定されること
を保証しなければならない。事実上、ここでいうグラニ
ュールは、その範囲内では変換が均一であることを保証
できるネットワーク・アドレス（ＩＰアドレス、ポート
番号）の最大単位である。
【００２７】まず、前記で名づけられた第１の下位問
題、すなわち、転送中に行われる変換の動的発見を検討
しよう。そのような変換は、ＩＰパケットの内容、特に
ＴＣＰ及びＵＤＰポート番号に依存することがある。事
前に変換を明示的に計算する容易な方法はないが、これ
は、この種の計算のために必要な情報（ＮＡＴの内部設
定及び状態）が容易に利用可能でなく、また利用可能に
することができないからである。
【００２８】本発明による方法では、通信中のピアは、
相互間の通信経路全体を通じて少なくとも１つのプロー
ビング・パケットを送信し、何が起こるか監視すること
で、発生する変換をプロービングする。プロービング・
パケット−または短く「プローブ」とも言う−は、それ
に対して行われる変換が実際のデータ・パケットに対し
て行われるものと同じであるように、実在のデータ・パ
ケットと十分に同様のものでなければならない。プロー
ブを受信するシステムもそれをプローブとして認識する
ことができなければならない。また、本発明のこの部分
は、プロービング情報を各方向に送信される第１データ
・パケットに含めることによっても実現できる。これら
の２つの選択肢を独立プロービング及びインライン・プ
ロービングと呼ぶ。
【００２９】場合によっては、変換情報がある宛先
（「デフォルト」宛先を含むことがある）について手動
で設定されることがある。このような場合、特性をプロ
ービングによって決定する必要はない。その代わり、特
性は設定情報から直接決定される。例えば、図１のセッ
トアップは十分に単純であり、この場合は手動設定が実
行可能である。しかし、手動設定は、例えばＩＰｖ４対
ＩＰｖ６の変換に関する必要な情報が全く利用できない
場合一般に不可能である。
【００３０】独立またはインライン・プロービングの代
案のうち、まず独立プロービングを検討しよう。ここで
は、図６によれば、送信ノード６０１は独立プローブ・
パケット６０２を受信ノード６０３に送信する。受信ノ
ードはプローブ・パケットをプローブ・パケットとして
認識しなければならない。プローブ・パケットは、デー
タ・パケットと同じプロトコル（例えばＡＨ、ＥＳＰ、
ＴＣＰまたはＵＤＰ）とポート番号（適用可能な場合）
を使用しなければならないので、この可能性は制限され
ている。それがプローブ・パケットであることを判定す
る選択肢には以下のものが含まれる。
【００３１】パケット７０１のデータ部分７０２中の専
用コンテンツ（例えば、キー・マネージャによってネゴ
シエートされるいわゆるマジック・クッキー７０３、ま
たはその派生物）。これは図７に図示される。マジック
・クッキー７０３は十分に長いビット・ストリングとな
りうるので、それが通常のパケットに現れる確率は極め
て低い（事実上ゼロである）。
【００３２】パケットのヘッダ中の専用フラグ（例え
ば、ＩＰ、ＴＣＰまたはＵＤＰヘッダ中の予備フラグを
使用）、または何らかのフィールド中に異質な値を有す
る。ＩＰ、ＴＣＰまたはＵＤＰヘッダ中の専用ヘッダ
（例えば特にこの目的のために予約されるＩＰオプショ
ン）。これは図８に図示される。パケットをプローブと
して識別するためのオプションとして専用オプション番
号が使用される。
【００３３】受信ノードが、あるプロトコル、アドレス
及びポートの組合せの次のパケットをプローブと見なす
ような状態に置かれる。この状態は、送信ノードと通信
するキー・マネージャによって設定及びクリアできる。
本発明は、受信ノードでプローブを認識するために使用
される方法を制限しない。
【００３４】独立プローブが全通信経路を移動し、受信
ノードがそれをプローブとして認識した後、転送中にど
んな変換が行われたかの決定は、プローブの元のコンテ
ンツ（典型的にはヘッダ）を受信端で見られるものと比
較することによってなされる。この比較は送信ノードま
たは受信ノードの何れかによってなされる。受信ノード
でなされる場合、比較を行うための十分な情報を受信ノ
ードに伝えなければならない（プローブ・パケット自体
のデータ部分中で、または例えばキー・マネージャを使
用する他の通信によって）。送信ノードでなされる場
合、受信ノードは、比較を可能にするために受信パケッ
トに関する十分な情報を返送しなければならない。情報
を伝える１つの可能な形態は、パケットのデータ部分で
すべての元のヘッダまたは受信ヘッダを相手側に送信す
ることである。（パケットのデータ部分を修正する変換
はまれであり、通常セキュリティの見地から許容されな
い。）図９のインライン・プロービングの実施形態で
は、プロービング情報は最初のデータ・パケット９０１
と共に送信される。インライン・プロービングには、非
破壊形及び破壊形プロービングという２つの可能な形態
がある。非破壊形プロービングでは、パケット９０１は
受信ノード９０２にとって全く通常のデータ・パケット
に見えるので、使用されるプロービング機構を知らない
場合、受信ノードはプロービング情報を無視し、それを
通常のデータ・パケットとして処理する。他方、破壊形
プロービングでは、受信ノード９０２はプロービング方
法を知らないとパケットを正常に処理することができな
い。
【００３５】破壊形プロービングは、最初のデータ・パ
ケットのデータもプロービング情報と同じＩＰパケット
に含まれていること以外は、独立プローブ・パケットを
使用するのと同様である。非破壊形プローブは、受信ノ
ード９０２がそれを理解しない場合受信ノードによって
無視されるので、この場合本発明は適用できない。パケ
ット認証通信は、ノードがそれらに対処する適切な方法
をサポートしない場合不可能となる。この場合受信ノー
ドが回答パケットを返送しても、それはプローブに関す
る回答情報を含まない。このことは元の送信ノード９０
３によって、受信ノードがプロービングをサポートしな
かったことを判定するために使用される（変換が実際に
行われた場合、受信ノードはおそらくパケットを無視す
るだろうということに注意のこと）。受信ノードがプロ
ービング情報を理解した場合、本発明は適用可能であ
り、元の送信ノードへの回答パケットには、元の送信ノ
ードに送信する必要のある何らかの回答情報と、適切な
場合そのプローブ情報が含まれる。本発明の観点から、
元の受信ノードが最初の回答パケットを送信する時、元
の送信ノードの能力はすでに部分的に元の受信ノードに
知られているので、このパケットは非破壊形であること
もないこともある。
【００３６】回答パケットの役割は、プローブが受信さ
れ、受信ノードがパケット認証通信をサポートすること
を送信ノード９０３に確認することである。元のプロー
ビング・パケットまたは回答パケットがネットワーク内
で失われた場合、永久にか、または再試行回数を越える
まで何回も再送しなければならないことがある。前記で
説明したように、非破壊形インライン・プロービング
は、相手側がこの開示で説明された方法をサポートする
かをネゴシエートし、同時に動的発見を行う可能な方法
である。相手側がこれらの方法をサポートするかをネゴ
シエートするには、以下のような別の方法もある。
【００３７】キー・マネージャを使用してネゴシエート
する（例えば、ベンダＩＤペイロード及び／または基本
プロトコルの拡張を使用するＩＳＡＫＭＰ／Ｏａｋｌｅ
ｙによって）。ネットワーク毎、またはホスト毎に事前
設定する。独立またはインラインどちらのプロービング
が使用されたかとは無関係に、行われる変換の補償を可
能にするために必要な要求は、補償を行うノード（送信
または受信ノード）がどんな変換が行われたかを知って
いることである。双方向接続では、補償は各パケットに
ついて、対応する送信ノードか、対応する受信ノード
か、またはパケットの方向と無関係に常に同じ側によっ
て行われる。変換の判定は、受信パケット（ヘッダ）を
送信されたパケット（ヘッダ）と比較することで最も容
易に行われる。これを行うためには、受信ヘッダを送信
ノードに伝えるか、または元の形の送信ヘッダを受信ノ
ードに伝えるかしなければならない。この通信は、イン
ライン・プロービング交換の一部としてか、またはキー
・マネージャ通信を通じてか、または他の方法で行われ
る。元のヘッダを受信ノードに送信することと、受信ヘ
ッダを送信ノードに戻すことはどちらも実行可能な選択
肢である。
【００３８】ここで、どの変換が補償のために許容可能
か、という前記で規定された第２の下位問題の一部とし
て、送信及び受信パケット・ヘッダの比較を検討しよ
う。パケットに対して行われうる変換には、以下のよう
ないくつかの種類がある。ＩＰアドレスとポート番号が
変更される。これは典型的にはＮＡＴによって行われ
る。「内部」及び「外部」アドレスのマッピングは個々
の通信の間一定であるが、同じアドレスとポートが後で
再使用されるならば／される時、マッピングが異なるこ
とがある。
【００３９】ＩＰオプションが除去される。例えば、ゲ
ートウェイによっては送信元ルーティング情報を全て除
去するものがある。ＩＰオプションが追加される。例え
ば、ゲートウェイによってはＩＰＳＯまたはＣＩＰＳＯ
オプションをパケットに追加するものがある。ＩＰｖ４
とＩＰｖ６の間でパケットが変換される。これは基本ヘ
ッダ・レイアウトの変更、ＩＰオプションの順序変更、
アドレスの変換（但しこれはごく簡単なもののことがあ
る）を伴い、ＭＡＣの計算方法を変更することがある。
これには一部のオプションの追加／除去を伴うこともあ
るが、オプションによってはパケットに転送されるもの
もある。特に今後数年間に発生が見込まれる移行期間に
は、パケットはこうした変換を行ったり来たりすること
になるだろう。送信ノードと受信ノードが通信のため別
のプロトコルを使用することもありうる（例えば、一方
がＩＰｖ４を使用し、他方がＩＰｖ６を使用する）。別
のゲートウェイの使用が、あるオプションを異なって処
理したり、または異なった形で順序付けることも考えな
ければならない。
【００４０】ＩＰとある全く別のプロトコルの間、また
は２つの全く異なったプロトコルの間でパケットが変換
される。こうした変換を通じてパケットの認証を維持す
ることは極めて困難または実行不可能になるが、やはり
本発明の可能な適用業務である。いわゆるＤＮＳ情報を
ＮＡＴ内部に見られるＩＰアドレスに対応させるため、
ＮＡＴ装置で内部に含まれるＩＰアドレスを修正するよ
うな状況によってパケットのデータ部分が修正される。
【００４１】比較はまず、１つの主要なプロトコルから
別のプロトコル（例えば、ＩＰｖ４対ＩＰｖ６）への変
換を検査することによって行われる。ＩＰの場合、比較
の残りの部分は以下のように行われる。ヘッダを、例え
ば、ＩＰ送信元アドレス、ＩＰ宛先アドレス、プロトコ
ル（ＴＣＰ／ＵＤＰ／他）、送信元ポート、宛先ポー
ト、ＩＰオプション、ＴＣＰ／ＵＤＰオプション、等と
いったフィールドに分割する。
【００４２】大部分のフィールドは単純に比較できる
（例えば、アドレス、プロトコル、ポート）。一部の変
換は明らかに常に許容できなくて（例えば、プロトコル
番号の変更）、比較は失敗する。セキュリティの考慮に
よって他の制約が課されることがある。ＩＰオプション
は追加、除去または再順序付けといったいくつかの種類
の変更を受けることがある。しかし、典型的には、パケ
ットはＩＰオプションを有さないものが大部分であり、
ローカル・セキュリティ・ポリシーによって一般に使用
または許可されるオプションはごく少数である。変更さ
れる可能性のあるオプションはさらに少ない。セキュリ
ティの考慮からはごく特定の種類の変更だけを許容する
可能性が最も高い。
【００４３】ＴＣＰヘッダを通常のネットワーク・ゲー
トウェイが変更することはおそらくまれである。大部分
の実現はおそらくＴＣＰヘッダの変更を許可できない。
セキュリティの考慮とは、どちらかの誤った警報を出す
という認証手順の危険を判定する、すなわち正当な変換
だけが行われているにもかかわらず認証を拒否するか、
または不正な変換を気付かずに通すという意味である。
危険の許容可能なレベルは転送されるデータの重要性に
よって変化する。適切な危険レベルと、その結果生じる
正当な変換とみなされるものに対する制約は、特定の本
発明の作用なしに実験によって発見される。
【００４４】ネットワークを通じた経路で行われる変換
は、通信が稼動中（active）である間に突然変更されう
ることが考えられる。これは例えば、ＩＰｖ４の代わり
にＩＰｖ６を使用するためリンクが更新される場合に発
生する。こうした変更はまれであり、おそらく無視でき
る。しかし、これに対処したい場合、稼動中の通信の最
中で誤って認証されたパケットを受信した時、再び動的
発見手順を行うことが可能である。しかし、ごく少数の
誤って認証されたパケットを送信することによるサービ
ス拒否の開始を避けるため、このような再発見がサポー
トされている場合は注意しなければならない。
【００４５】セキュリティの考慮は、変換の動的発見を
行う際重要である。許容されるのは一部の種類の変換だ
けである。もし任意の変換が許容されたならば、攻撃者
は、相手側にネットワークで変換が行われたと考えさせ
ることで、送信元ＩＰアドレスとポートを自由に偽造す
ることができるであろう。セキュリティ問題は、ＮＡＴ
が送信ノードと受信ノードの実際のＩＰアドレスを隠す
ことが多いという事実によって複雑になっている。各当
事者（each party）は実際のマシンのアドレスでなく、
相手側のファイアウォールに属するアドレスだけを見る
ことになる。
【００４６】変換の補償が、ＭＡＣの計算または検証中
に相手側で見られるアドレスを代用する側によって行わ
れると想定するならば、この代用を行うノードは相手側
ノードの真のＩＰアドレスを知る必要があるであろう。
しかし、この必要条件を回避する方法がある。ＮＡＴ背
後の各ノードが、ＮＡＴゲートウェイの外側で有するＩ
Ｐアドレス（及び他の情報）を知ることができるなら、
その情報を使用してＭＡＣを計算することができ、その
情報をその真のアドレスとして受信ノードに伝えること
ができる。同様の手順は受信ノードにも適用される。
【００４７】ここで、セキュリティの考慮に戻ろう。基
本的には、受信パケットが、発信元だと考えられる送信
ノードから実際に発信されたことを認証したい。真の送
信ノードに関する情報には、以下のものを含むいくつか
の可能な情報源がある。ピアが合意した何らかの認証キ
ーを使用することによって認証された送信ノードによっ
て、パケットと共に送信される（インライン・プロービ
ング）。送信ノードのアイデンティティ（identity）
は、認証キーについて合意がなされた時、受信ノードの
知るところとなっている。
【００４８】特定のセキュリティ・アソシエーション
（security association）に関連するアイデンティティ
として、キー・マネージャを使用して伝えられている。
この情報はキー・マネージャ間のキー交換の際に認証さ
れている。セキュリティ・アソシエーションについて合
意された何らかの認証キーによって認証された、プロー
ブ・パケット中で送信される。
【００４９】パケットが暗号化手段によって十分に保護
されている（パケット認証とプライバシ保護の両方）と
想定すれば、パケットがネットワークの中のどんな経路
を通過するかは実際には気にしない。その意味では、重
要な情報が適切な本当の端点でネゴシエートされたこと
が確実である限り、パケット中のＩＰアドレスまたはポ
ートを気にすることはない。ＩＰアドレスは信頼できな
いので、この情報は（本発明を適用するかどうかとは無
関係に）ＩＰアドレス以外の手段によって認証されなけ
ればならない。
【００５０】他の通信ノードを認証し、その認証を検証
して通信を行うために現在使用されているいくつかの周
知の方法があり、それには以下のものが含まれる。手動
で設定された固定キー（「このキーを知っている者と通
信してよい」）。事前に共有された秘密によって認証さ
れる、動的に合意されたキー（「この秘密を知っている
者と通信してよい」）。
【００５１】信頼できる認証局（ＣＡ）による電子証明
書（「信頼できる認証局（ＣＡ）による電子証明書を有
する者と通信してよい」）。特定のネットワーク・アド
レス範囲を対象とする、信頼できる認証局（ＣＡ）によ
る電子証明書（「使用するＩＰアドレスについて信頼で
きる認証局（ＣＡ）による電子証明書を提示できる者と
通信してよい」）。
【００５２】他のノードに、別のノードと通信する認証
を与える信頼できる機関による証明（例えば、ＳＰＫＩ
証明書を使用する）。他の形態とポリシーも可能であ
り、近年のうちに発展する見込みである。これらの方法
には通信中の遠隔ノードまたはユーザのアイデンティテ
ィを直接生じるものと（例えば、信頼できる認証局によ
る電子証明書に関連する名前の形態で）、認証のみを生
じ、遠隔ノードまたはユーザのアイデンティティに関し
ては関与しないものがある。
【００５３】何れにしても、ＮＡＴが使用される時、ア
ドレスは多かれ少なかれランダムなので（通常アドレス
範囲の中で）、遠隔ノードによって使用されるＩＰアド
レスとポート番号は認証目的ではあまり価値を有さな
い。従って、トラフィックが他の方法で認証されても、
ＮＡＴが存在する際ＩＰアドレスとポートは実際には認
証用に使用できない。通信中のノードの認証は、キー交
換プロトコルの一部として交換された電子証明書または
他の情報を使用してなされなければならない。
【００５４】すなわち、受信ノードに示されるＩＰアド
レスを本当に気にすることはない。そのアドレスを認証
する必要はない（かつ、ＮＡＴゲートウェイによる変換
で生じるアドレスの範囲を示す証明書を要求しないなら
ば、アドレスを認証するためにできることは多くな
い）。しかし、パケット内のどこかの変更を補償する偽
のアドレスを伝える攻撃を避けるため、補償を行うノー
ドに伝えられる情報は認証しなければならない。よいＭ
ＡＣは補償アドレスの判定を許可しないという議論は可
能だが、常にアドレスを認証する方が安全である。パケ
ットの残りの部分を認証するために使用されるものと同
じ認証キーを使用して伝えられた情報を認証するのが好
都合である。
【００５５】ノードのローカル・セキュリティ・ポリシ
ーは、得られる認証の各形態についてどの変換が許容可
能であると見なすかを決定する。この種のポリシーは多
くのものが可能である。１つの可能なポリシーを以下概
説する。ＩＰｖ４とＩＰｖ６以外のプロトコルの変更は
許可しない。フォーマットの変更を補償し、ＩＰｖ４対
ＩＰｖ６の変換を許容する。
【００５６】通信開始側の送信元アドレスとポートの任
意の変更を許容する。応答側の証明書によって明示的に
許可されていない限り、開始側の宛先アドレスまたは応
答側の送信元アドレスの変更は許可しない。しかし、Ｉ
Ｐｖ４と対応するＩＰｖ６のアドレス（ＩＰｖ６アドレ
ス定義に規定されている）間の変換は常に許可される。
【００５７】プロトコル番号の変更（ＴＣＰ対ＵＤＰ対
他のプロトコル）は許可しない。ＴＣＰ及びＵＤＰ以外
のプロトコルに関するポート番号は無視する。ＩＰオプ
ション、ＴＣＰオプション、またはパケットの他の部分
の変更は許可しない。本発明はポリシーの選択を制限し
ない。
【００５８】セキュリティ・ポリシーは通常、設定デー
タベースに対する検査として実現される。しかし、多く
の適用業務では、セキュリティ・ポリシーまたはその態
様の一部は静的である。こうした静的な態様はコードの
中で暗黙に実現されることが多い。例えば、あるヘッダ
・フィールドの変更の許可は、単にそのフィールドを検
査しないという形で実現できる。同様に、あるフィール
ド（またはプロトコル）に特定の値を有するよう要求す
ることは簡単な比較であり、例えば、本方法が実現され
るプラットフォーム上のパケット・ルーティング・コー
ドまたは他の無関係なコードによって暗黙に行うことも
できる。
【００５９】行われる変換が判定されれば、それらを通
信中のノードの１つまたは両方によって補償しなければ
ならないが、これは前記で定義された第３の下位問題で
ある。インライン・プロービングが使用されている場
合、受信ノードが許容可能な変換を補償するための十分
な情報をプローブ・パケット自体が含んでいる。しか
し、全てのパケットにこのような情報を含めることはネ
ットワーク帯域幅の浪費であるため望ましくない。従っ
て、全てのパケットに明示的な補償情報を含める代わり
に、行われる変換に関する記録を補償を行うノードに保
持し、記録された情報を使用して変換を補償することが
おそらく望ましい。
【００６０】補償は、パケットの送信時にＭＡＣを計算
する時か、またはパケットの受信後にＭＡＣを検証する
時かの何れかに行われる。ＭＡＣは通常、暗号として強
力な適切なハッシュ関数（または取り扱いにくいやり方
でビットを混合する他の関数）を使用することで、パケ
ット・コンテンツと秘密キーから以下のように計算され
る。
【００６１】秘密キーはＭＡＣに含まれている。パケッ
ト・データはＭＡＣに含まれている。パケット・ヘッダ
の適用できる部分は全てＭＡＣに含まれている。ＴＴＬ
フィールドのような、パケットが送信される間に通常、
変更されるいくつかのフィールドがある。これらはＭＡ
Ｃの計算には含まれない（またはＭＡＣの計算の前にゼ
ロにされる）。他の大部分のフィールドはＭＡＣの計算
に含まれる。
【００６２】送信元及び宛先アドレスは通常ＭＡＣの計
算に含まれる。ＥＳＰでは、ＭＡＣは通常パケット・デ
ータだけを対象にし、ヘッダは対象にしない。しかしさ
らに高レベルのプロトコル・チェックサム（例えばＴＣ
ＰまたはＵＤＰチェックサム）はヘッダからのデータを
含むことがある。ＭＡＣは典型的には、全てのビットが
ＭＡＣに取り扱いにくいやり方で含まれる全てのビット
に依存するビット・ベクトルである。ＭＡＣ中のビット
の数は十分に大きく（換言すれば、ＭＡＣは十分に強力
であり）、ある特定のＭＡＣに一致するデータを発見す
ることは実行不可能である。これはすなわち、キーを知
らなければ、ある特定のキーによってうまく検証するこ
とのできるＭＡＣを生成することはできないということ
である。
【００６３】送信ノードで変換を補償するために、送信
ノードはＭＡＣを計算する前に受信ノードによって見ら
れる変換を適用する。すなわち、送信パケット中のＭＡ
Ｃは送信ノードが送信するパケットに一致せず、受信ノ
ードが見るパケットに一致する。受信ノードで変換を補
償するために、受信ノードはＭＡＣを計算する前に受信
データに逆変換を適用する。すなわち、送信ノードは正
しいＭＡＣを有するパケットを送信し、受信ノードはＭ
ＡＣを検証する前に、そのパケットを送信ノードによっ
て送信された形式に変換する。
【００６４】ＭＡＣ中の変更を補償することに加えて、
補償を行うノードは、パケット認証が行われない場合通
常ＮＡＴ装置によって行われる追加補償動作を行うこと
がある。例えば、パケットに対して行われた変更によっ
てＴＣＰまたはＵＤＰチェックサムが更新されることが
ある。こうした更新は増分更新（本質的に古い値を差し
引き、新しい値をチェックサムに加える）としてか、ま
たはチェックサム全体を再計算することで実現される。
【００６５】ＥＳＰパケットの場合、時には動的発見と
ＭＡＣ補償の下位処理全体を回避できることもある。こ
れはＥＳＰパケットヘッダがＭＡＣに含まれず、ＭＡＣ
を計算する必要がないからである。セキュリティ・ポリ
シーは、有効なＭＡＣがパケットに存在する限りパケッ
ト・ヘッダ（ＩＰアドレス）のどんな変換も許容可能で
あるとすることがある。ＮＡＴに対する操作が、ＥＳＰ
について、外側ＩＰヘッダの変更を許可する一定のセキ
ュリティ・ポリシーのみによってサポートされるだけで
よければ、本発明は単に何れかの受信ＴＣＰまたはＵＤ
Ｐパケットのチェックサムを再計算することで実現でき
る。
【００６６】時には認証／暗号化パケットがデータ部分
の中にネットワーク・アドレスを含むことがある。１つ
の例はＤＮＳ（ドメイン名システム）パケットである。
この種のパケットはホスト名をＩＰアドレスにマッピン
グするために使用される。多くのＮＡＴはＤＮＳパケッ
トのコンテンツに対する変換を行う。この種の変換はパ
ケット・コンテンツが保護されている場合不可能にな
る。こうした場合、パケット・コンテンツに対する変換
の一部または全てを補償段階の一部として行うことが必
要になりうる。
【００６７】ＮＡＴの中には、ＩＰＳＥＣのようなセキ
ュリティ・プロトコルをも認識し、パケット中のＳＰＩ
（セキュリティ・パラメータ・インデックス）値に専用
マッピングを行うものもある。補償にはＳＰＩ値を元の
値のものへ変更することが含まれることもある。こうし
た状況では、元のＳＰＩ値はプローブ・パケットで伝え
られる。
【００６８】ここで、図１０の流れ図を参照して、本発
明の１つの可能な実現を詳細に検討しよう。簡単にする
ために、この実現はＩＰｖ４プロトコルのみを扱い、Ｉ
Ｐｖ４ ＮＡＴ（ＴＣＰ及びＵＤＰプロトコルに関する
ＩＰアドレスとポートの変換）に対処することだけを目
的とする。しかし、当業者には、本発明をＩＰｖ４−Ｉ
Ｐｖ６プロトコル変換または他の種類の変換に対処する
にはどのように拡張できるかが明らかであろう。ＩＰｖ
４パケットの認証のためＩＰＳＥＣ機構が使用されると
想定する。暗号化は考慮しない。しかし、ここでＡＨヘ
ッダを使用して説明されているものと同様に、認証は、
場合によっては暗号化と組み合わされるＥＳＰヘッダを
使用しても同様にうまく行われる。
【００６９】ここでは通信中のノードを開始側及び応答
側と呼ぶ。開始側とは最初のパケットを送信し通信を開
始するノードである。応答側は最初のパケットの送信先
である（かつ、典型的には、応答側は、１つかそれ以上
の回答パケットを返送することでそのパケットに応答す
る）。以下の説明では、ＮＡＴゲートウェイが開始側を
インターネットから分離し、応答側が自分自身のＩＰア
ドレスと実際のポート番号を使用してインターネット上
で見ることができる場合に議論を限定する。この一般的
なセットアップはそういうものとして周知であり、図１
に図示されたものである。 開始側が応答側と通信しよ
うとし、かつそれらが最近通信していない（すなわち、
それらの間にまだセキュリティ・アソシエーション・セ
ットアップがない）場合、まず開始側は応答側と一般に
１００１として指定されるＩＳＡＫＭＰ交換を開始す
る。これは通常ＵＤＰパケットを応答側のＩＰアドレス
のポート５００（ここで５００はポート番号であって参
照符号ではない）に送信することでなされる。ＮＡＴは
パケット中の送信元アドレスと送信元ポートを置換す
る。開始側と応答側双方のキー・マネージャがＩＳＡＫ
ＭＰパケットを交換し、キー・マネージャ間のＩＳＡＫ
ＭＰセキュリティ・アソシエーションをセットアップす
る。この処理の一部として、それらはＩＳＡＫＭＰによ
ってサポートされる何らかの方法を使用して互いに認証
（または許可）する。
【００７０】次に、一般に１００２として指定される段
階で、開始側と応答側の間でＩＰＳＥＣ ＳＡ（セキュ
リティ・アソシエーション）が生成される（実際には各
方向に１つずつ、２つ）。共有秘密キーが各ＳＡに関連
するが、これはＳＡを使用して送信されるトラフィック
を保護するために使用されるＩＰＳＥＣ変換（暗号化及
び認証アルゴリズム）のための重要な構成要素を導出す
るために使用される。
【００７１】キー交換中にある種の変換がＩＳＡＫＭＰ
パケットで行われたということもありうる。しかし、デ
ータは別のポート番号を使用して転送され別のマッピン
グを有しうるので、その変換を使用してデータ・パケッ
トで行われる変換を決定することはできない。この時点
まで接続セットアップは従来技術によって進行してい
る。
【００７２】次に段階１００３で最初のデータ・パケッ
トが開始側から応答側に送信される。パケットは認証さ
れ、キー交換期間中にネゴシエートされたようにＡＨ及
びＥＳＰヘッダを使用して、保護される。さらに、専用
ＩＰオプションがパケットに追加される。このＩＰオプ
ションは専用の予備番号を有し、開始側と応答側の間の
通信チャネルの変換特性をプロービングするために使用
される。これは非破壊形インライン・プロービングの変
形である。このオプションのフォーマットとコンテンツ
は図１１に記述されている。ＭＡＣ１１０１は例えば、
パケットで使用される認証変換と同じキーを使用するオ
プションの残りの部分のＨＭＡＣ−ＳＨＡ１の最初の９
６ビットであることがある。「プローブの受信」フィー
ルド１１０２の値は偽であり、まだ相手側からプローブ
・パケットを受信していないことを示す。使用特定（im
plementation-specific ）データ１１０３は、開始側に
よってサポートされる機能に関する情報といった、相手
側に伝える必要のある任意のデータである。パケットが
送信された時の元のＩＰヘッダ１１０４も示される。
【００７３】興味深いことだが、ＮＡＴがポート番号を
変更する場合でも、ＡＨ／ＥＳＰカプセル化はＴＣＰ／
ＵＤＰヘッダをＮＡＴから隠すので、ＮＡＴはポート番
号を修正できる見込みは少ないということに注意のこ
と。ＮＡＴはここでは、ポート番号を修正していくつか
のアドレスを同じアドレスに多重化する代わりに、接続
をオープンにする内部アドレス毎に１つの外部アドレス
を割り当てなければならないので、ＮＡＴの性能に対し
て有害な影響を有することにもなる。本発明は、ＮＡＴ
がＡＨ／ＥＳＰヘッダ内部のポート番号を変更する場合
にも適用可能である。
【００７４】プローブ回答を受信する前に別のパケット
が開始側から応答側に送信されるならば、そのパケット
は同様のプローブ・オプションを含む。段階１００４で
このフォーマットのパケットを受信すると、応答側は受
信プローブ・オプション中のデータを受信ＩＰパケット
中の情報と比較する。応答側はこの比較を使用し、パケ
ットの転送中に行われた変換に対する逆変換を生成す
る。このデータは、同じＳＡを使用して受信されるその
後のパケットを処理する際に使用し、最初のパケットを
開始側に送信する時開始側に応答するために記録され
る。
【００７５】段階１００５で最初のパケットを開始側に
送信すると、応答側は開始側から受信された最初のパケ
ットにプローブ・オプションが存在したかを検査する。
存在した場合、最初のパケットには自分自身のプローブ
・オプションが含まれる。このプローブ・オプションは
開始側によって送信されたものと同一であるが、「プロ
ーブの受信」フィールドが真になり、応答側がすでにプ
ローブを受信しており開始側がそれ以上プローブを送信
する必要がないことを示す点が異なっている。
【００７６】段階１００６でこのパケットを受信した後
の次のパケットには、開始側はまだプローブ・オプショ
ンを含めているが、ここでは「プローブの受信」フィー
ルドは真であり、応答側がそれ以上プローブを送信する
必要がないことを示す。パケットの交換が円滑に進行し
たならば、アドレス変換（及びプロトコル変換、但しこ
れは図１０に関しては特に論じられない）の動的発見が
完了し、開始側と応答側はパケットの交換を継続し、段
階１００４及び１００６で保存されたアドレス変換（及
びプロトコル変換）に関する情報により、同じＳＡを使
用して受信されるその後のパケットを処理する。
【００７７】しかし、複雑な状況があることもある。シ
ステムは失われたパケットを処理できなければならな
い。また、相互間のＳＡがセットアップされたが応答側
が開始側から最初のパケットを受信していない時点で、
応答側が自発的にパケットを送信側に送信したいという
可能性もわずかだが存在する。プローブの送信に関する
適切な動作は図１２の状態機械によって要約できる。状
態の概念は各ＳＡに別々に関連する。
【００７８】前記で扱われていない問題は、セキュリテ
ィ・アソシエーションの細分性対変換情報の細分性とい
う問題である。ＳＡは、多数のホストを対象にするすべ
てのサブネット間に存在することも、例えば１つのＴＣ
Ｐ／ＩＰポート対のみに関するものであることもある。
他方、変換情報は通常ホスト毎にのみ一定であるか、ま
たさらにはポート毎にしか一定でない（ＡＨ及びＥＳＰ
ヘッダのためにポート情報がＮＡＴに見えない場合はポ
ート毎ではありえない）。
【００７９】これは、変換に関する情報を、ＳＡか、ま
たはおそらくはＳＡにリンクされた各ホスト／ポートに
関する変換情報を記録する独立データ構造かのどちらに
保存するかという問題を提起する。どちらのアプローチ
も可能である。ここでは独立データ構造が使用され、Ｓ
Ａの対象となる各ホストに関する変換情報を別個に記録
することと想定する。
【００８０】図１３は、図１０の方法で開始側または応
答側の役目を果たすネットワーク装置１３００の簡易ブ
ロック図である。ネットワーク・インタフェース１３０
１はネットワーク装置１３００を物理的にネットワーク
に接続する。アドレス管理ブロック１３０２はネットワ
ーク装置１３００自体とそのピア（図示せず）両方の正
しいネットワーク・アドレス、ポート番号及び他の必須
の公開識別情報を見守る。ＩＳＡＫＭＰブロック１３０
３は秘密情報の交換に関するキー管理処理及び他の作業
（activity）に責任を負う。暗号化／解読ブロック１３
０４は、ＩＳＡＫＭＰブロック１３０３によって秘密キ
ーが得られていれば、データの暗号化と解読を実現す
る。補償ブロック１３０５は、本発明によって送信及び
／または受信パケットの許容可能な変換を補償するため
に使用される。パケット組み立て／分解ブロック１３０
６は、ブロック１３０２〜１３０５と物理ネットワーク
・インタフェース１３０１の間の仲介者である。全ての
ブロックは制御ブロック１３０７の監視の元で動作する
が、制御ブロック１３０７はまた、例えばディスプレイ
・ユニット（図示せず）を通じて情報をユーザに表示
し、キーボード（図示せず）を通じて指令をユーザから
得るため、他のブロックとネットワーク装置の残りの部
分の間の情報のルーティングを処理する。図１３のブロ
ックは最も有利にはマイクロプロセッサの事前プログラ
ム操作手順として実現されるが、この実現自体は当業者
に周知である。図１３に示されたもの以外の装置も同様
に本発明を実行するため使用されることがある。 ［図面の簡単な説明］
【図１】図１は、内部ネットワークと外部ネットワーク
の間の周知のＮＡＴ装置を図示する。
【図２】図２は、周知のＩＰｖ４パケット・ヘッダを図
示する。
【図３】図３は、周知のＩｐｖ６パケット・ヘッダを図
示する。
【図４】図４は、周知のパケット・ヘッダを図示する。
【図５】図５ａ及び図５ｂは、周知のパケット・ヘッダ
を図示する。
【図６】図６は、本発明による独立プロービングを図示
する。
【図７】図７は、本発明による、送信されるパケットを
操作する様々な方法を図示する。
【図８】図８は、本発明による、送信されるパケットを
操作する様々な方法を図示する。
【図９】図９は、本発明によるインライン・プロービン
グを図示する。
【図１０】図１０は、本発明の実施形態を流れ図として
図示する。
【図１１】図１１は、図１０の細部を図示する。
【図１２】図１２は、本発明の実施形態を状態機械とし
て図示する。
【図１３】図１３は、本発明による装置のブロック図を
図示する。
───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平６−30079（ＪＰ，Ａ) 特開 平８−102761（ＪＰ，Ａ) 特開 平８−307413（ＪＰ，Ａ) 特開 平４−160954（ＪＰ，Ａ) 特開 昭60−140（ＪＰ，Ａ) 米国特許5633931（ＵＳ，Ａ) (58)調査した分野(Int.Cl.7，ＤＢ名) H04L 12/00 H04L 9/00

Claims (22)

    (57)【特許請求の範囲】
  1. 【請求項１】 ネットワークにおいて送信ノード（９０
    ３）と受信ノード（９０２）の間の適用可能なセキュリ
    ティ・ポリシーによってパケット認証を達成する方法で
    あって、 前記送信ノードと前記受信ノードの間で転送されるパケ
    ットに対して行われる変換を動的に発見するステップ
    （１００３、１００４）と、 前記適用可能なセキュリティ・ポリシーに基づいて前記
    発見された変換が許容可能であることを検査するステッ
    プ（１００４）と、 前記送信ノードから前記受信ノードに送信されるパケッ
    トを認証する前に、前記動的に発見された許容可能な変
    換を補償するステップ（１００４、１００６）とを含む
    ことを特徴とする方法。
  2. 【請求項２】 前記送信ノード（９０３）から前記受信
    ノード（９０２）に送信される各パケットが、秘密キー
    と元の前記パケットのコンテンツから導出された暗号化
    認証コード（１１０１）を含むことを特徴とする、請求
    項１に記載の方法。
  3. 【請求項３】 前記動的に発見された変換を補償するた
    め、前記暗号化認証コード（１１０１）を計算する前
    に、元のパケットのコンテンツが前記送信ノード（９０
    ３）で操作されることを特徴とする、請求項２に記載の
    方法。
  4. 【請求項４】 前記動的に発見された変換を補償するた
    め、前記暗号化認証コード（１００１）を検証する前
    に、受信パケットのコンテンツが前記受信ノード（９０
    ２）で操作されることを特徴とする、請求項２に記載の
    方法。
  5. 【請求項５】 前記送信ノード（９０３）から前記受信
    ノード（９０２）に転送される少なくとも１つのデータ
    ・パケット（６０２、９０１）が元のパケット・ヘッダ
    （１１０４）の少なくとも一部分のセーブされたコピー
    を含み、前記受信ノードが、受信パケットの前記暗号化
    認証コードを検証する時前記パケット・ヘッダ中の前記
    セーブされたコピーを使用することを特徴とする、請求
    項４に記載の方法。
  6. 【請求項６】 前記セーブされたコピーが前記パケット
    ・ヘッダの専用オプション中に保存されることを特徴と
    する、請求項５に記載の方法。
  7. 【請求項７】 前記専用オプションがＩＰオプションで
    あることを特徴とする、請求項６に記載の方法。
  8. 【請求項８】 前記セーブされたコピーが暗号的に認証
    されることを特徴とする、請求項５に記載の方法。
  9. 【請求項９】 前記送信ノードから前記受信ノードにパ
    ケットを転送する際に適用される基本的なプロトコルが
    ＩＰｖ４プロトコルであり、パケット認証がＩＰＳＥＣ
    プロトコルを使用してなされることを特徴とする、請求
    項１に記載の方法。
  10. 【請求項１０】 前記送信ノードから前記受信ノードに
    パケットを転送する際に適用される基本的なプロトコル
    がＩＰｖ６プロトコルであることを特徴とする、請求項
    １に記載の方法。
  11. 【請求項１１】 前記変換がＩＰアドレス変換（１０
    ０）を含むことを特徴とする、請求項１に記載の方法。
  12. 【請求項１２】 前記変換がＴＣＰ／ＵＤＰポート変換
    を含むことを特徴とする、請求項１に記載の方法。
  13. 【請求項１３】 前記動的に発見された許容可能な変換
    を補償する前記ステップ（１００４、１００６）が、Ｔ
    ＣＰまたはＵＤＰチェックサムを更新する下位ステップ
    を含むことを特徴とする、請求項１に記載の方法。
  14. 【請求項１４】 前記変換が前記ＩＰｖ４及びＩＰｖ６
    プロトコル間の変換を含むことを特徴とする、請求項１
    に記載の方法。
  15. 【請求項１５】 前記動的発見が、非破壊形インライン
    ・プロービング、破壊形インライン・プロービング、独
    立プロービングから選択されるプロービング方法を使用
    してなされることを特徴とする、請求項１に記載の方
    法。
  16. 【請求項１６】 前記プロービング方法が、前記送信ノ
    ードから前記受信ノードにプローブ（１００３）を送信
    するステップを含み、前記プローブが通常のデータ・パ
    ケットと同じネットワーク・アドレスに送信されるパケ
    ットであることを特徴とする、請求項１５に記載の方
    法。
  17. 【請求項１７】 前記プローブの受信に対する応答とし
    て前記受信ノードがプローブ回答（１００５）を前記送
    信ノードに送信することを特徴とする、請求項１６に記
    載の方法。
  18. 【請求項１８】 前記通信中のノードが、転送中の変換
    が存在する際にそれらノードの両者が認証をサポートす
    るかをネゴシエートすることを特徴とする、請求項１に
    記載の方法。
  19. 【請求項１９】 変換特性が、前記通信中のノード間の
    経路上の最も細かい細分性の変換に帰結する十分に小さ
    な細分性で決定されることを保証するステップを含むこ
    とを特徴とする、請求項１に記載の方法。
  20. 【請求項２０】 ネットワークにおいて送信ノード（９
    ０３）と受信ノード（９０２）の間の適用可能なセキュ
    リティ・ポリシーによるヘッダを備えるパケットについ
    てパケット認証を達成する方法であって、 メッセージ認証コード中にパケット・ヘッダを含まない
    認証コード機構の使用と、 前記適用可能なセキュリティ・ポリシーに基づく、前記
    送信ノードと前記受信ノードの間で転送されるパケット
    に対して行われる前記発見された変換が許容可能である
    ことの検査（１００４）と、 前記送信ノードから前記受信ノードに送信されるパケッ
    トを認証する前の前記許容可能な変換の補償（１００
    ４、１００６）とを備えることを特徴とする方法。
  21. 【請求項２１】 適用可能なセキュリティ・ポリシーに
    よるパケット認証形式のデジタル情報をネットワーク中
    の他のネットワーク装置に送信するネットワーク装置
    （１３００）であって、 それと前記他のネットワーク装置の間で転送されるパケ
    ットに対して行われる変換を動的に発見するためと、 前記適用可能なセキュリティ・ポリシーに基づいて前記
    発見された変換が許容可能であることを検査するため
    と、 認証されるパケットを前記他のネットワーク装置に送信
    する前に前記動的に発見された許容可能な変換を補償す
    るためとの手段（１３０５、１３０６、１３０７）を備
    えることを特徴とするネットワーク装置。
  22. 【請求項２２】 適用可能なセキュリティ・ポリシーに
    よるパケット認証形式のデジタル情報をネットワーク中
    の他のネットワーク装置から受信するネットワーク装置
    （１３００）であって、 それと前記他のネットワーク装置の間で転送されるパケ
    ットに対して行われる前記変換を動的に発見するため
    と、 前記適用可能なセキュリティ・ポリシーに基づいて前記
    発見された変換が許容可能であることを検査するため
    と、 前記他のネットワーク装置から受信されたパケットを認
    証する前に前記動的に発見された許容可能な変換を補償
    するためとの手段（１３０５、１３０６、１３０７）を
    備えることを特徴とするネットワーク装置。
JP2000528056A 1997-12-31 1998-12-30 ネットワーク・アドレス変換とプロトコル変換が存在する場合のパケット認証の方法 Expired - Fee Related JP3457645B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FI974665A FI105753B (fi) 1997-12-31 1997-12-31 Pakettien autentisointimenetelmä verkko-osoitemuutosten ja protokollamuunnosten läsnäollessa
FI974665 1997-12-31
PCT/FI1998/001032 WO1999035799A2 (en) 1997-12-31 1998-12-30 A method for packet authentication in the presence of network address translations and protocol conversions

Publications (2)

Publication Number Publication Date
JP2002501332A JP2002501332A (ja) 2002-01-15
JP3457645B2 true JP3457645B2 (ja) 2003-10-20

Family

ID=8550255

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000528056A Expired - Fee Related JP3457645B2 (ja) 1997-12-31 1998-12-30 ネットワーク・アドレス変換とプロトコル変換が存在する場合のパケット認証の方法

Country Status (10)

Country Link
US (1) US6795917B1 (ja)
EP (1) EP1036460B1 (ja)
JP (1) JP3457645B2 (ja)
AT (1) ATE307449T1 (ja)
AU (1) AU1879599A (ja)
CA (1) CA2315722C (ja)
DE (1) DE69831974T2 (ja)
FI (1) FI105753B (ja)
IL (1) IL136787A0 (ja)
WO (1) WO1999035799A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007043374A (ja) * 2005-08-02 2007-02-15 Matsushita Electric Ind Co Ltd Ｉｐ通信装置及びそれを備えた構内ネットワークシステム並びにｉｐ通信装置の制御方法

Families Citing this family (114)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9603582D0 (en) 1996-02-20 1996-04-17 Hewlett Packard Co Method of accessing service resource items that are for use in a telecommunications system
US5898830A (en) * 1996-10-17 1999-04-27 Network Engineering Software Firewall providing enhanced network security and user transparency
US6324685B1 (en) 1998-03-18 2001-11-27 Becomm Corporation Applet server that provides applets in various forms
JP4273535B2 (ja) * 1998-05-12 2009-06-03 ソニー株式会社 データ伝送制御方法、データ伝送システム、データ受信装置及びデータ送信装置
ES2760905T3 (es) 1998-10-30 2020-05-18 Virnetx Inc Un protocolo de red agile para comunicaciones seguras con disponibilidad asegurada de sistema
US6826616B2 (en) 1998-10-30 2004-11-30 Science Applications International Corp. Method for establishing secure communication link between computers of virtual private network
US7418504B2 (en) 1998-10-30 2008-08-26 Virnetx, Inc. Agile network protocol for secure communications using secure domain names
US10511573B2 (en) 1998-10-30 2019-12-17 Virnetx, Inc. Agile network protocol for secure communications using secure domain names
US6502135B1 (en) 1998-10-30 2002-12-31 Science Applications International Corporation Agile network protocol for secure communications with assured system availability
FI106417B (fi) * 1998-12-08 2001-01-31 Nokia Mobile Phones Ltd Menetelmä tiedonsiirron optimoimiseksi
US7107614B1 (en) 1999-01-29 2006-09-12 International Business Machines Corporation System and method for network address translation integration with IP security
US6957346B1 (en) * 1999-06-15 2005-10-18 Ssh Communications Security Ltd. Method and arrangement for providing security through network address translations using tunneling and compensations
US6657969B1 (en) 1999-06-29 2003-12-02 Cisco Technology, Inc. Generation of synchronous transport signal data used for network protection operation
US6629163B1 (en) 1999-12-29 2003-09-30 Implicit Networks, Inc. Method and system for demultiplexing a first sequence of packet components to identify specific components wherein subsequent components are processed without re-identifying components
US6614785B1 (en) 2000-01-05 2003-09-02 Cisco Technology, Inc. Automatic propagation of circuit information in a communications network
CA2399014A1 (en) * 2000-01-28 2001-08-02 At&T Corp. Method and apparatus for firewall with multiple addresses
US7058973B1 (en) * 2000-03-03 2006-06-06 Symantec Corporation Network address translation gateway for local area networks using local IP addresses and non-translatable port addresses
US7573915B1 (en) * 2000-04-25 2009-08-11 Cisco Technology, Inc. Method and apparatus for transporting network management information in a telecommunications network
JP4265087B2 (ja) * 2000-06-29 2009-05-20 ソニー株式会社 データ変換装置及び方法、データ送受信装置及び方法、ネットワークシステム
KR100358518B1 (ko) * 2000-07-03 2002-10-30 주식회사 지모컴 임베디드 하드웨어와 범용 컴퓨터가 결합된 방화벽 시스템
US7155740B2 (en) * 2000-07-13 2006-12-26 Lucent Technologies Inc. Method and apparatus for robust NAT interoperation with IPSEC'S IKE and ESP tunnel mode
JP4365998B2 (ja) * 2000-07-21 2009-11-18 株式会社日立製作所 マルチキャスト通信方法および通信装置
FR2812991B1 (fr) * 2000-08-08 2003-01-24 France Telecom Traduction d'identificateurs de terminaux d'installation d'usager dans un reseau de paquets
US20020124090A1 (en) * 2000-08-18 2002-09-05 Poier Skye M. Method and apparatus for data communication between a plurality of parties
KR100645960B1 (ko) * 2000-08-29 2006-11-14 삼성전자주식회사 사설망의 네트워크 노드에 접속하기 위한 시스템과 방법
EP1187415A1 (de) * 2000-09-05 2002-03-13 Siemens Aktiengesellschaft Verfahren zur Identifikation von Internet-Nutzern
FI111423B (fi) 2000-11-28 2003-07-15 Nokia Corp Järjestelmä kanavanvaihdon jälkeen tapahtuvan tietoliikenteen salauksen varmistamiseksi
US20020103926A1 (en) * 2000-12-19 2002-08-01 Alcatel Usa Sourcing, L.P. Method of transparently transporting sonet STS-3C frame information across a network
US9954686B2 (en) 2001-01-18 2018-04-24 Virnetx, Inc. Systems and methods for certifying devices to communicate securely
US7209479B2 (en) 2001-01-18 2007-04-24 Science Application International Corp. Third party VPN certification
US7197565B2 (en) * 2001-01-22 2007-03-27 Sun Microsystems, Inc. System and method of using a pipe advertisement for a peer-to-peer network entity in peer-to-peer presence detection
US7165107B2 (en) * 2001-01-22 2007-01-16 Sun Microsystems, Inc. System and method for dynamic, transparent migration of services
WO2002057917A2 (en) 2001-01-22 2002-07-25 Sun Microsystems, Inc. Peer-to-peer network computing platform
US7272636B2 (en) * 2001-04-24 2007-09-18 Sun Microsystems, Inc. Peer group name server
US7061899B2 (en) * 2001-05-01 2006-06-13 Hewlett-Packard Development Company, L.P. Method and apparatus for providing network security
US7450578B2 (en) * 2001-06-01 2008-11-11 Fujitsu Limited Method of addressing and routing data
WO2003019404A1 (en) * 2001-08-30 2003-03-06 Riverhead Networks Inc. Protecting against distributed denial of service attacks
US20030046532A1 (en) * 2001-08-31 2003-03-06 Matthew Gast System and method for accelerating cryptographically secured transactions
US20030046535A1 (en) * 2001-09-06 2003-03-06 Nelson Dean S. System and method for authenticating use of a network appliance
GB0123419D0 (en) * 2001-09-28 2001-11-21 Memquest Ltd Data handling system
DE10209502B4 (de) * 2001-10-25 2017-12-28 Nec Europe Ltd. Verfahren zur Übermittlung von Daten
DE60139883D1 (de) * 2001-11-29 2009-10-22 Stonesoft Oy Kundenspezifische Firewall
US7013342B2 (en) * 2001-12-10 2006-03-14 Packeteer, Inc. Dynamic tunnel probing in a communications network
US7181616B2 (en) * 2001-12-12 2007-02-20 Nortel Networks Limited Method of and apparatus for data transmission
FI118170B (fi) * 2002-01-22 2007-07-31 Netseal Mobility Technologies Menetelmä ja järjestelmä viestin lähettämiseksi turvallisen yhteyden läpi
US7500102B2 (en) * 2002-01-25 2009-03-03 Microsoft Corporation Method and apparatus for fragmenting and reassembling internet key exchange data packets
US7590855B2 (en) * 2002-04-30 2009-09-15 Tippingpoint Technologies, Inc. Steganographically authenticated packet traffic
US7558873B1 (en) 2002-05-08 2009-07-07 Nvidia Corporation Method for compressed large send
US7676579B2 (en) 2002-05-13 2010-03-09 Sony Computer Entertainment America Inc. Peer to peer network communication
US7243141B2 (en) 2002-05-13 2007-07-10 Sony Computer Entertainment America, Inc. Network configuration evaluation
US7370194B2 (en) * 2002-06-10 2008-05-06 Microsoft Corporation Security gateway for online console-based gaming
US7191331B2 (en) 2002-06-13 2007-03-13 Nvidia Corporation Detection of support for security protocol and address translation integration
US7120930B2 (en) 2002-06-13 2006-10-10 Nvidia Corporation Method and apparatus for control of security protocol negotiation
GB2418821B (en) * 2002-06-13 2006-08-09 Nvidia Corp Method and apparatus for enhanced security for communication over a network
US7143137B2 (en) * 2002-06-13 2006-11-28 Nvidia Corporation Method and apparatus for security protocol and address translation integration
GB2413248B (en) * 2002-06-13 2006-06-21 Nvidia Corp Method and apparatus for enhanced security for communication over a network
US7143188B2 (en) 2002-06-13 2006-11-28 Nvidia Corporation Method and apparatus for network address translation integration with internet protocol security
US7043247B2 (en) * 2002-07-01 2006-05-09 Interdigital Technology Corporation Routing header based routing in internet protocol (IP)-cellular networks
US7437548B1 (en) 2002-07-11 2008-10-14 Nvidia Corporation Network level protocol negotiation and operation
US7139841B1 (en) * 2002-07-24 2006-11-21 Cisco Technology, Inc. Method and apparatus for handling embedded address in data sent through multiple network address translation (NAT) devices
US7849140B2 (en) * 2002-08-29 2010-12-07 Oracle America, Inc. Peer-to-peer email messaging
US7263560B2 (en) * 2002-08-30 2007-08-28 Sun Microsystems, Inc. Decentralized peer-to-peer advertisement
KR100492490B1 (ko) * 2002-10-31 2005-06-02 크로스반도체기술 주식회사 IPv4/IPv6 변환에 있어서 TCP 세그먼트/UDP 데이터그램의체크섬 계산 장치 및 방법
US7237030B2 (en) * 2002-12-03 2007-06-26 Sun Microsystems, Inc. System and method for preserving post data on a server system
US7386881B2 (en) * 2003-01-21 2008-06-10 Swander Brian D Method for mapping security associations to clients operating behind a network address translation device
US8245032B2 (en) * 2003-03-27 2012-08-14 Avaya Inc. Method to authenticate packet payloads
FR2853187B1 (fr) * 2003-03-28 2006-01-13 At & T Corp Systeme permettant a toute application reseau de fonctionner de facon transparente a travers un dispositif de traduction d'adresse de reseau
US7620070B1 (en) 2003-06-24 2009-11-17 Nvidia Corporation Packet processing with re-insertion into network interface circuitry
WO2005004393A1 (en) * 2003-07-03 2005-01-13 Koninklijke Philips Electronics N.V. Secure indirect addressing
KR101055861B1 (ko) * 2003-08-08 2011-08-09 케이코 오가와 통신 시스템, 통신 장치, 통신 방법 및 그것을 실현하기위한 통신 프로그램
US7631181B2 (en) * 2003-09-22 2009-12-08 Canon Kabushiki Kaisha Communication apparatus and method, and program for applying security policy
US7574603B2 (en) * 2003-11-14 2009-08-11 Microsoft Corporation Method of negotiating security parameters and authenticating users interconnected to a network
US7257572B2 (en) * 2004-04-30 2007-08-14 Intel Corporation Function for directing packets
US20050268331A1 (en) * 2004-05-25 2005-12-01 Franck Le Extension to the firewall configuration protocols and features
US8179784B2 (en) * 2004-07-16 2012-05-15 Hewlett-Packard Development Company, L.P. Method and apparatus for recovering a communications connection
US7664109B2 (en) * 2004-09-03 2010-02-16 Microsoft Corporation System and method for distributed streaming of scalable media
US8117452B2 (en) * 2004-11-03 2012-02-14 Cisco Technology, Inc. System and method for establishing a secure association between a dedicated appliance and a computing platform
CN100414929C (zh) * 2005-03-15 2008-08-27 华为技术有限公司 一种移动互联网协议网络中的报文传送方法
US7917950B2 (en) * 2005-05-12 2011-03-29 Jds Uniphase Corporation Protocol-generic eavesdropping network device
WO2006134442A2 (en) * 2005-06-14 2006-12-21 Nokia Corporation Apparatus, method and computer program product providing high performance communication bus having preferred path source routing, multi-guarantee qos and resource reservation, management and release
JP4489008B2 (ja) 2005-11-16 2010-06-23 株式会社東芝 通信装置、通信方法および通信プログラム
KR100814400B1 (ko) * 2006-01-12 2008-03-18 삼성전자주식회사 ＩＰｖ４／ＩＰｖ６ 통합 네트워크 시스템의 보안 통신방법 및 그 장치
US8032874B1 (en) * 2006-01-20 2011-10-04 Xilinx, Inc. Generation of executable threads having source code specifications that describe network packets
JP2007201564A (ja) * 2006-01-23 2007-08-09 Nec Corp 推定システム、端末、推定方法、およびプログラム
CN101056218B (zh) * 2006-04-14 2012-08-08 华为技术有限公司 一种网络性能测量方法及***
CN101056217B (zh) * 2006-04-14 2011-01-19 华为技术有限公司 一种网络性能测量方法及***
US8281383B2 (en) * 2006-12-11 2012-10-02 Cisco Technology, Inc. Secured IPv6 traffic preemption
US8156557B2 (en) * 2007-01-04 2012-04-10 Cisco Technology, Inc. Protection against reflection distributed denial of service attacks
KR101356736B1 (ko) * 2007-01-19 2014-02-06 삼성전자주식회사 콘텐츠의 무결성을 확인하기 위한 콘텐츠 제공 장치 및방법 및 콘텐츠 사용 장치 및 방법, 및 콘텐츠 사용 장치를폐지하는 콘텐츠 제공 장치 및 방법
US7933273B2 (en) 2007-07-27 2011-04-26 Sony Computer Entertainment Inc. Cooperative NAT behavior discovery
US7908393B2 (en) 2007-12-04 2011-03-15 Sony Computer Entertainment Inc. Network bandwidth detection, distribution and traffic prioritization
US7856506B2 (en) 2008-03-05 2010-12-21 Sony Computer Entertainment Inc. Traversal of symmetric network address translator for multiple simultaneous connections
US8739289B2 (en) * 2008-04-04 2014-05-27 Microsoft Corporation Hardware interface for enabling direct access and security assessment sharing
US8391495B2 (en) * 2008-05-08 2013-03-05 International Business Machines Corporation Secure shell used to open a user's encrypted file system keystore
US20090282460A1 (en) * 2008-05-12 2009-11-12 Raytheon Company System and Method for Transferring Information Through a Trusted Network
KR101510472B1 (ko) * 2008-10-02 2015-04-08 삼성전자주식회사 무선 센서 네트워크의 데이터 패킷을 보안하기 위한 장치 및 방법
US8238538B2 (en) 2009-05-28 2012-08-07 Comcast Cable Communications, Llc Stateful home phone service
US8289970B2 (en) * 2009-07-17 2012-10-16 Microsoft Corporation IPSec encapsulation mode
CN102223353A (zh) * 2010-04-14 2011-10-19 华为技术有限公司 主机标识协议安全通道复用方法及装置
US9294506B2 (en) * 2010-05-17 2016-03-22 Certes Networks, Inc. Method and apparatus for security encapsulating IP datagrams
TWI500768B (zh) * 2010-07-05 2015-09-21 Metabolic Explorer Sa 由蔗糖製備１，３－丙二醇之方法
US8966240B2 (en) * 2011-10-05 2015-02-24 Cisco Technology, Inc. Enabling packet handling information in the clear for MACSEC protected frames
US9154484B2 (en) * 2013-02-21 2015-10-06 Cisco Technology, Inc. Identity propagation
US9967372B2 (en) 2015-10-13 2018-05-08 Cisco Technology, Inc. Multi-hop WAN MACsec over IP
US10397186B2 (en) 2017-10-06 2019-08-27 Stealthpath, Inc. Methods for internet communication security
US10361859B2 (en) 2017-10-06 2019-07-23 Stealthpath, Inc. Methods for internet communication security
US10375019B2 (en) 2017-10-06 2019-08-06 Stealthpath, Inc. Methods for internet communication security
US10374803B2 (en) 2017-10-06 2019-08-06 Stealthpath, Inc. Methods for internet communication security
US10367811B2 (en) 2017-10-06 2019-07-30 Stealthpath, Inc. Methods for internet communication security
US10630642B2 (en) 2017-10-06 2020-04-21 Stealthpath, Inc. Methods for internet communication security
US11558423B2 (en) 2019-09-27 2023-01-17 Stealthpath, Inc. Methods for zero trust security with high quality of service
WO2021146311A1 (en) * 2020-01-13 2021-07-22 Pulse Secure, Llc Dynamically updating network routes
CN111541696B (zh) * 2020-04-24 2021-10-01 清华大学 随机认证嵌入的快速源和路径验证方法
US11863561B2 (en) * 2021-11-10 2024-01-02 Oracle International Corporation Edge attestation for authorization of a computing node in a cloud infrastructure system

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5577209A (en) * 1991-07-11 1996-11-19 Itt Corporation Apparatus and method for providing multi-level security for communication among computers and terminals on a network
US5349642A (en) * 1992-11-03 1994-09-20 Novell, Inc. Method and apparatus for authentication of client server communication
US5864683A (en) * 1994-10-12 1999-01-26 Secure Computing Corporartion System for providing secure internetwork by connecting type enforcing secure computers to external network for limiting access to data based on user and process access rights
US5633931A (en) * 1995-06-30 1997-05-27 Novell, Inc. Method and apparatus for calculating message signatures in advance
US5793763A (en) 1995-11-03 1998-08-11 Cisco Technology, Inc. Security system for network address translation systems
JP3688830B2 (ja) 1995-11-30 2005-08-31 株式会社東芝 パケット転送方法及びパケット処理装置
ATE221677T1 (de) * 1996-02-09 2002-08-15 Digital Privacy Inc Zugriffssteuerungs/verschlüsselungssystem
FR2745966B1 (fr) * 1996-03-08 1998-06-05 Jean Luc Leleu Passerelle de peage pour reseau de transmission de donnees
JP2982727B2 (ja) * 1996-08-15 1999-11-29 日本電気株式会社 認証方法
JP3492865B2 (ja) * 1996-10-16 2004-02-03 株式会社東芝 移動計算機装置及びパケット暗号化認証方法
JP3557056B2 (ja) * 1996-10-25 2004-08-25 株式会社東芝 パケット検査装置、移動計算機装置及びパケット転送方法
JP3651721B2 (ja) * 1996-11-01 2005-05-25 株式会社東芝 移動計算機装置、パケット処理装置及び通信制御方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007043374A (ja) * 2005-08-02 2007-02-15 Matsushita Electric Ind Co Ltd Ｉｐ通信装置及びそれを備えた構内ネットワークシステム並びにｉｐ通信装置の制御方法

Also Published As

Publication number Publication date
CA2315722A1 (en) 1999-07-15
DE69831974D1 (de) 2005-11-24
IL136787A0 (en) 2001-06-14
EP1036460A2 (en) 2000-09-20
FI974665A0 (fi) 1997-12-31
FI974665A (fi) 1999-07-01
EP1036460B1 (en) 2005-10-19
US6795917B1 (en) 2004-09-21
JP2002501332A (ja) 2002-01-15
CA2315722C (en) 2007-12-04
WO1999035799A3 (en) 1999-09-10
WO1999035799A2 (en) 1999-07-15
ATE307449T1 (de) 2005-11-15
AU1879599A (en) 1999-07-26
FI105753B (fi) 2000-09-29
DE69831974T2 (de) 2006-06-08

Similar Documents

Publication Publication Date Title
JP3457645B2 (ja) ネットワーク・アドレス変換とプロトコル変換が存在する場合のパケット認証の方法
US9838362B2 (en) Method and system for sending a message through a secure connection
Patel et al. Securing L2TP using IPsec
Frankel et al. Ip security (ipsec) and internet key exchange (ike) document roadmap
US6101543A (en) Pseudo network adapter for frame capture, encapsulation and encryption
Winter et al. Transport layer security (TLS) encryption for RADIUS
US7903671B2 (en) Service for NAT traversal using IPSEC
JP2009111437A (ja) ネットワークシステム
Aboba et al. Securing block storage protocols over ip
US20230336529A1 (en) Enhanced privacy preserving access to a vpn service
JP2011054182A (ja) ディジタルバトンを使用するシステムおよび方法、メッセージを認証するためのファイアウォール、装置、および、コンピュータ読み取り可能な媒体
US20150381387A1 (en) System and Method for Facilitating Communication between Multiple Networks
KR102059150B1 (ko) IPsec 가상 사설 네트워크 시스템
KR100450774B1 (ko) ＮＡＴ 기능을 갖는 사설망에서 ＩＰＳｅｃ을 이용한종단과 종단 간의 ｐｒｉｖａｔｅ 정보 전송 방법 및 이를이용한 보안 서비스 방법
Hughes IPsec and IKEv2
Patel et al. RFC3193: Securing L2TP using IPsec
Winter et al. RFC 6614: Transport Layer Security (TLS) Encryption for RADIUS
JP2005191646A (ja) 遮断装置、匿名公開鍵証明書発行装置、システム、および、プログラム
Gabriel-Robez VPN and Firewall Traversal
Aboba et al. RFC3723: Securing Block Storage Protocols over IP
Demerjian et al. Network Security using E-DHCP over NAT/IPSEC.
Zorn et al. Network Working Group B. Patel Request for Comments: 3193 Intel Category: Standards Track B. Aboba W. Dixon Microsoft
Sommerfeld et al. Secure Neighbor Discovery Working J. Arkko Group Ericsson Internet-Draft J. Kempf Expires: July 24, 2004 DoCoMo Communications Labs USA

Legal Events

Date Code Title Description
R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

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

Free format text: PAYMENT UNTIL: 20070801

Year of fee payment: 4

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

Free format text: PAYMENT UNTIL: 20080801

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20080801

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20090801

Year of fee payment: 6

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

Free format text: PAYMENT UNTIL: 20090801

Year of fee payment: 6

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

Free format text: PAYMENT UNTIL: 20100801

Year of fee payment: 7

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

Free format text: PAYMENT UNTIL: 20110801

Year of fee payment: 8

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

Free format text: PAYMENT UNTIL: 20110801

Year of fee payment: 8

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

Free format text: PAYMENT UNTIL: 20120801

Year of fee payment: 9

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

Free format text: PAYMENT UNTIL: 20130801

Year of fee payment: 10

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees