JP2008535080A - 順不同で配信されるデータの保護 - Google Patents

順不同で配信されるデータの保護 Download PDF

Info

Publication number
JP2008535080A
JP2008535080A JP2008503989A JP2008503989A JP2008535080A JP 2008535080 A JP2008535080 A JP 2008535080A JP 2008503989 A JP2008503989 A JP 2008503989A JP 2008503989 A JP2008503989 A JP 2008503989A JP 2008535080 A JP2008535080 A JP 2008535080A
Authority
JP
Japan
Prior art keywords
delivery
unordered
data
security
protocol
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
Application number
JP2008503989A
Other languages
English (en)
Other versions
JP4903780B2 (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 JP2008535080A publication Critical patent/JP2008535080A/ja
Application granted granted Critical
Publication of JP4903780B2 publication Critical patent/JP4903780B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor

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)
  • Computer And Data Communications (AREA)

Abstract

本発明の基本概念は、信頼性のあるトランスポートプロトコルの上位で動作するセキュリティプロトコルで順序化配信データと非順序化配信データとを分離し、セキュリティプロトコルで、順序化配信データ用の第１タイプのセキュリティ処理と、非順序化配信データ用の第２タイプのセキュリティ処理を実行することである。好ましくは、セキュアデータストリーム内の順序化配信を使用するデータメッセージと非順序化配信を使用するデータメッセージは、セキュリティプロトコルレイヤ上で２つのメッセージシーケンス空間に分離され、データセキュリティ処理が、２つのメッセージシーケンス空間で別々に実行される。

Description

発明の分野
本発明は、信頼性のある転送プロトコル（reliable transport protocol）のセキュリティに関するものであり、詳しくは、順不同で配信されるデータの保護に関するものである。
発明の背景
一般的には、本発明は、順序付けされた（ordered：順序化）データの配信及び順序付けされていない（unordered：非順序化）データの配信をサポートする信頼性のある転送プロトコルに関係する。ストリーム制御送信プロトコル（ＳＣＴＰ）文献［１］は、このような転送プロトコルの例であり、これは、ＩＥＴＦのＳＩＧＴＲＡＮワーキンググループで開発されている。これは、当初は、ＰＳＴＮテレフォニーシグナリングメッセージを搬送するために設計されていた。これは、ＴＣＰでは利用できないが、いくつかの有用な特徴を有しているので、今日では、汎用転送プロトコルとされていて、また、ＴＣＰに代るものとされている。
通常は、ＳＣＴＰストリーム内では、データメッセージは、それらのストリームシーケンス番号に従う順序で配信される。データメッセージが順不同で受信エンドポイントに到達する場合（即ち、以前から）、そのデータメッセージの前にあるデータメッセージのすべてが受信され、かつ上位レイヤに配信されるまで、そのデータメッセージの上位レイヤへの配信は保留されなければならない。ＳＣＴＰエンドポイントは、順序化配信が、ストリーム内で送信される特定のＤＡＴＡチャンク（chunk：塊）に対して必要とされないことを示すことができる。エンドポイントが非順序化配信で示されるＤＡＴＡチャンクを受信する場合、ＳＣＴＰ非順序化配信を示す図１で示されるように、これは、順序化メカニズムをバイパスして、直ちにそのデータを上位レイヤに配信することができる。
非順序化配信は、アプリケーションが大量の独立トランザクションを処理する場合でのヘッドオブライン（ＨＯＬ）ブロッキングの回避に有用である。ＨＯＬブロッキングは、複数の独立トランザクションが順序通りにシングルデータストリームで搬送され（例えば、ＴＣＰ接続）、かつそれらの独立トランザクションの内の１つでいくつかのデータが遅延する場合に発生する。そのデータ到達が遅延する独立トランザクションと、それ以外の独立トランザクションとが相関してないとしても、その遅延データが到達するまで、その独立トランザクションの後に続く他のトランザクションのすべては、上位レイヤへの配信がブロックされ、かつ待機しなければならない。
この種のアプリケーションの例は、転送プロトコルとしてＳＣＴＰを使用してシグナリングメッセージを交換するＳＩＰプロキシ群を示す図２で示されるように、複数のＳＩＰエージェント２０−Ａ及び２０−Ｂに対する、２つのＳＩＰプロキシ１０−Ａ及び１０−Ｂ間のＳＩＰシグナリングメッセージ（例えば、呼セットアップ／メッセージ分解、課金情報及び転送クエリーメッセージ）の転送がある。これらのＳＩＰシグナリングメッセージは、互いに独立していて、これらのシグナリングメッセージの到達順序は重要ではない。しかしながら、それらが適時に到達することは重要である。ＳＩＰプロキシ間のＳＩＰシグナリングメッセージを搬送するためにＳＣＴＰの非順序化配信を使用することは、ＴＣＰで存在するＨＯＬブロッキングを回避し、また、ＳＣＴＰの非順序化配信を用いることで、ＳＩＰトランザクションのＳＩＰメッセージの損失が、他のトランザクションのＳＩＰメッセージの適時配信に逆影響を与えることはない。ＨＯＬブロッキングは、ＳＣＴＰのマルチストリーミング特性を使用することによっても回避することができる（即ち、各ＳＩＰトランザクションを、自身が所有するＳＣＴＰストリームに割り当てる）。しかしながら、このことは、より多くのストリームリソースを必要とし、実現可能でない可能性がある。文献［２］では、ＳＩＰシグナリングメッセージを搬送するためにＳＣＴＰが使用される場合、非順序化配信を用いて、ＳＩＰエンティティは、各ＳＩＰメッセージをゼロストリームを介して送信すべきであることを明確に示している。
別の例には、ＡＡＡ（認証、認可及びアカウンティング）メッセージの転送がある。ユーザが、ネットワーク内のセキュリティゲートウェイあるいは他のエンティティを認証する場合、そのエンティティはそのユーザを認証するために必要な不可欠な情報を通常は含んでない。一方、ＤＩＡＭＥＴＥＲプロトコルは、ＤＩＡＭＥＴＲサーバを用いる典型的な認証を使用する場合を示す図３で示されるように、ＡＡＡサーバからセッション認証情報を取得するために使用される。ＡＡＡサーバ３０とアクセスゲートウェイ４０間のインタフェースのＨＯＬブロッキングを回避するために、ＳＣＴＰの非順序化配信方法を使用することができる、あるいは各ユーザ５０に対して別々の信頼性のあるストリームを確立することができる。このインタフェースは通常保護されていて、また、ＴＬＳ（トランスポートレイヤセキュリティ）プロトコルが広く選択されている。ＴＬＳは非順序化配信（以下で説明するように）を用いて使用することができないので、上述のようなより多くのストリームリソースを必要とするマルチストリーミングが頻繁に使用される。このシステムセットアップが使用される例には、文献［３］で定義される汎用ブートストラップアーキテクチャがある。
ＳＣＴＰアソシエーションのデータセキュリティが、ネットワークレイヤのＩＰ認証ヘッダ（ＡＨ）文献［４］あるいはＩＰカプセル化ヘッダ（ＥＳＰ）文献［５］を使用することによって達成することができることが文献［１］で説明されている。しかしながら、ＡＨ及びＥＳＰは、ミドルボックスのようなデバイスと互換性がない。ＳＣＴＰアソシエーションのデータセキュリティも、トランスポートレイヤの上位のトランスポートレイヤセキュリティ（ＴＬＳ）プロトコル文献［６］を使用することによって達成することができるが、これは、順序化配信に対してのみである。順序化配信に対し、ＳＣＴＰを介するＴＬＳを使用することが、文献［７］に記載されている。文献［８］は、ＤＴＬＳ（データグラムトランスポートレイヤセキュリティ）プロトコルを記載していて、これは、すべてのＤＴＬＳレコードに対してシーケンス番号に基づく処理を使用する、ＴＬＳのデータグラム互換改良型である。
発明の要約
本発明は、従来技術の構成の上記の欠点及び他の欠点を解消する。
本発明の一般的な目的は、データの順序化配信とデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに対するセキュリティを改善することである。
特に、後述するように、非順序化配信機能を使用するデータに対して、トランスポートレイヤの上位でのセキュリティソリューションを提供することが望ましい。
また、有用なストリームリソースを無駄にすることなく、必要とされるセキュリティを提供することが望ましい。
特別な目的は、データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに対するデータセキュリティを提供する方法及びシステムを提供することである。
本発明の別の目的は、データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに基づいて動作するように構成されている受信機及び送信機を提供することである。
更なる目的は、そのようなトランスポートプロトコルとともに動作するように構成されているディスパッチャを提供することである。
これらの目的及び他の目的は、添付の特許請求の範囲によって定義される発明によって達成される。
本発明の基本概念は、信頼性のあるトランスポートプロトコルの上位で動作するセキュリティプロトコルで順序化配信データと非順序化配信データとを分離し、そのセキュリティプロトコルで、順序化配信データ用の第１タイプのセキュリティ処理と、非順序化配信データ用の第２タイプのセキュリティ処理を実行することである。好ましくは、セキュアデータストリーム内の順序化配信を使用するデータメッセージと非順序化配信を使用するデータメッセージは、セキュリティプロトコルレイヤ上で２つのメッセージシーケンス空間に分離され、データセキュリティ処理が、２つのメッセージシーケンス空間で別々に実行される。
本発明は、特に、ＳＣＴＰ（ストリーム制御送信プロトコル）のような信頼性のあるトランスポートプロトコルに対して適している。このトランスポートプロトコルの上位で動作するセキュリティプロトコルは、ＴＬＳ（トランスポートレイヤセキュリティ）、あるいは非順序化配信用のセキュリティ処理拡張を有するＴＬＳのようなプロトコルに基づいていることが好ましい。しかしながら、セキュリティプロトコルとトランスポートプロトコルの他の組み合わせを用いることもができることが理解されるべきである。
非順序化メッセージの識別を可能にするために、非順序化メッセージに向けられている専用メッセージタイプを導入することは有効である。送信側では、新規のメッセージタイプのメッセージそれぞれは、非順序化メッセージに向けられている専用シーケンス番号空間から明確なシーケンス番号が割り当てられることが好ましい。受信側では、非順序化配信メッセージ用のセキュリティ処理は、通常は、非順序化配信メッセージによって搬送される明確なシーケンス番号の処理に基づいている。
効率的な方法で、非順序化配信メッセージ用の再生保護を実行するために、受信されている非順序化メッセージの概念リスト、あるいは受信されていない非順序化メッセージのその概念リストの代替リストを保持することが有益である。
データ損失保護に対しては、セキュリティプロトコル接続の切断用の切断メッセージは、一般的には、送信済の非順序化配信メッセージの最終シーケンス番号を含んでいて、非順序化レコード空間内の送信済のすべてのレコードの信頼性のある受信は、切断メッセージの最終シーケンス番号に基づいて検出することができる。
本発明は、ＵＤＰ、ＤＣＣＰ及びＰＲ−ＳＣＴＰのような既存プロトコルと高い互換性があり、かつ完全に動作可能である。
本発明は、以下の効果を提供する。
データセキュリティの改善
非順序化配信機能を使用するトランスポートレイヤの上位での耐性がありかつ有効なセキュリティソリューション
有用なストリームリソースの効率的な利用を伴うデータセキュリティ
既存のトランスポートプロトコルとの高い互換性
本発明によって提供される他の効果は、以下の本発明の実施形態の説明を読むことによって理解されるであろう。
実施形態の詳細説明
図面全体を通して、同一の参照文字は、対応するあるいは同様の要素のために使用するものである。
特定の例示的な環境で、問題解析を開始することは有用であろう。非順序化配信機能を使用するＳＣＴＰアソシエーションは、ＡＨ及びＥＳＰによって保護することができる。しかしながら、ＡＨ及びＥＳＰはミドルボックス（例えば、ミドルボックスは、ＴＣＰパフォーマンス最適化、ヘッダ圧縮、アプリケーションゲートウェイの構築、ファイヤウォールの構築、ＮＡＴの実行等を行う）のようなデバイスとの互換性はない。これは、これらのミドルボックスが、トランスポートヘッダへアクセスあるいは操作することさえ必要とする場合があるからである。それゆえ、本発明は、ＳＣＴＰのようなプロトコルの非順序化配信機能を使用するデータ用トランスポートレイヤの上位におけるセキュリティソリューションの必要性を認識している。
ＴＬＳは、トランスポートレイヤの上位で動作するセキュリティプロトコルの例である。ＴＬＳは、本来、ＴＣＰ接続を介するデータを保護するために設計されている。ＴＬＳは、データストリームをセグメントに分割し、各セグメントに対して、暗号化及び認証を含むセキュリティ処理を実行し、その処理されたセグメントをデータレコードにカプセル化する。ＴＬＳでは、データチャンクあるいはデータメッセージは、通常、レコードとして参照される。従来のＴＬＳデータレコードのフォーマットが図４に示され、ここでは、レコードヘッダ、暗号化データ、及びＭＡＣ（メッセージ認証コード）を含んでいる。レコードヘッダは、通常は、レコードタイプフィールド、バージョン番号及びレコード長における情報を含んでいる。
ＴＬＳは、すべてのデータレコードが順番に到来するものと想定し、この想定に基づいてセキュリティ処理を実行する。それゆえ、データが順番に配信される場合に、ＴＬＳがＳＣＴＰをサポートするとしても、ＴＬＳは、非順序化配信を使用するデータを処理することができない。文献［７］では、ＳＣＴＰサービスの現在のＴＬＳサポートを示す図５で示されるように、ＳＣＴＰの非順序化配信機能はＴＬＳとともに使用されてはならないことが明確に記載されている。図５のプロトコルスタックでは、ＴＬＳはＳＣＴＰの非順序化配信に対して使用されないかわりに、ＳＣＴＰ順序化配信に対して使用されることが確認できる。
一般的には、本発明の基本概念は、図６のフロー図で示されるように、セキュリティプロトコルレイヤ上で、順序化配信用のデータメッセージと、非順序化配信用のデータメッセージを、２つのメッセージシーケンス空間に分離（Ｓ１）し、これらの２つの空間に異なるデータセキュリティ処理を実行する（Ｓ２）ことである。今日の従来技術のセキュリティプロトコル、例えば、ＴＬＳは、この識別を行うことができない。本発明の概念は、トランスポートレイヤの上位で、セキュリティプロトコルを設計／拡張し、そのセキュリティプロトコルレイヤで、順序化配信データと非順序化配信データとの分離を可能にし、そして、配信のタイプに依存して異なるタイプのセキュリティ処理を実行することである。
文献［８］は、ＤＴＬＳプロトコルを記載している。これは、実際には、非順序化配信を提供するものである。しかしながら、ＤＴＬＳでは、すべてのレコードは、明確なシーケンス番号を含んでいて、また、すべてのパケットが、そのシーケンス番号に基づく同一の方法でセキュリティ処理される。
本発明は、ＤＴＬＳとは区別されるものであり、本発明に従えば、順序化配信レコードと非順序化配信レコードが、２つ異なるレコードシーケンス空間に分離され、データセキュリティ処理が、順序化配信用と非順序化配信用とで別々に実行される。特に、本発明を用いると、シーケンス番号は、順不同のパケットに対してのみ挿入される。これに対して、ＤＴＬＳは、各レコードに対してそのような番号を挿入している。これによって、本発明のソリューションは、帯域幅を節約し、また、レガシーのＴＬＳとの互換性を持たせることができる。
更なる違いは、ＤＴＬＳが固定サイズの再生ウィンドウを提供するのに対し、本発明に従えば、別の方法が、順不同のレコードの追跡を維持するために使用され、この方法は、欠落しているシーケンス番号の間のサイズを考慮している。
本発明は、一般的には、信頼性のあるトランスポートプロトコルと、そのトランスポートレイヤの上位で動作するように設計されているセキュリティプロトコルとに適用可能である。但し、本発明は、特に、ＳＣＴＰ順序化配信用の基本セキュリティ処理とＳＣＴＰ非順序化配信用のセキュリティ処理拡張とを伴うＴＬＳ（トランスポートレイヤセキュリティ）に基づくセキュリティプロトコルと組み合わせた、ＳＣＴＰ（ストリーム制御送信プロトコル）に対して適している。このような状況では、このセキュリティ処理拡張の使用は、典型的には、セッションセットアップ中に、例えば、ハンドシェーク処理のような帯域内処理によってあるいは帯域外シグナリングによってネゴシエートされる。
送信側では、非順序化配信用のセキュリティ処理は、各非順序化データメッセージに、明確なシーケンス番号を、非順序化メッセージ専用のシーケンス番号空間から割り当てるように構成されていることが好ましい。受信側では、非順序化配信メッセージ用のセキュリティ処理は、通常は、非順序化配信メッセージによって搬送される明確なシーケンス番号の処理に基づくことになる。
以下では、本発明は、主に、特定のプロトコル例として、ＳＣＴＰとＴＬＳを参照して説明する。上述のように、本発明は、通常はこれに限定されるものではなく、他のセキュリティプロトコルとトランスポートプロトコルの組み合わせを用いることができることが理解されるべきである。
本発明の実施形態に従えば、図７に示されるように、セキュアストリーム内の順序化配信レコードと非順序化配信レコードとを２つのレコードシーケンス空間に分離し、これらの２つの異なる空間でデータセキュリティ処理を実行する。図７は、本発明の実施形態に従う、非順序化配信レコードに対するシーケンス空間の例を示している。非順序化配信シーケンス空間内には、対応するパケットに明示的に含まれるシーケンス番号だけとなっている。順序化配信シーケンス空間は、単に、セキュリティプロトコルによって内部的に処理され、また、ここでは、順序化パケットに存在する明確なシーケンス番号は存在しない。シーケンス空間の分離は、非順序化配信レコードに対して追加のレコードタイプを導入することによって達成されることが好ましい。例えば、ＴＬＳは、レコードヘッダ内に「タイプ」フィールド（図４参照）を持っていて、これは、異なるレコードタイプ（例えば、ハンドシェークメッセージ、アラートメッセージ及びアプリケーションデータ）を識別するために使用される。本発明に従えば、このフィールドは、レコードが非順序化レコードであることを特定するために使用することもできる（ここでは、すべての既存のタイプの非順序化バージョンとすることができる、あるいは完全に異なるものを定義することができる）。非順序化レコードの処理は、例えば、ＴＬＳのようなセキュリティプロトコルの拡張として実現することができ、また、この拡張の使用は、（ＴＬＳ）ハンドシェーク（順序化配信シーケンス空間で実行される）中の帯域内でネゴシエートを行うことで、レガシーの（ＴＬＳ）実装との後方互換性を持たせることができる。レガシーの（ＴＬＳ）実装が未知のレコードタイプに直面する場合、接続は切断されることになる。これは、レガシー（ＴＬＳ）実装は、新規のタイプのレコードを取得する場合には、簡単にクラッシュしないことを意味している。選択的には、非順序化配信レコード用のセキュリティ処理拡張の使用は、帯域外シグナリング（例えば、ＳＩＰシグナリング）によってネゴシエートされても良い。
このようなソリューションの可能なデータフロー例を、特に、ＴＬＳ及びＳＣＴＰを参照する図９に示す。送信側１００では、アプリケーション（Ｓ１１）がデータのチャンクをＴＬＳへ送信する場合（Ｓ１２）、配信のタイプ（即ち、順序化配信あるいは非順序化配信）を特定しないければならない。例えば、専用フラグ（０／１）がアプリケーションによって、例えば、順序化配信に対しては「０」、また、非順序化配信に対しては「１」を設定することができる。ＴＬＳ実装では、ディスパッチャが拡張されることが好ましい。ディスパッチャは、配信のタイプを識別し（Ｓ１３）、そして、アプリケーションによって特定される配信のタイプに従って、データをレガシーのＴＬＳプロトコルスタックへディスパッチする（Ｓ１４）、あるいはＳＣＴＰ非順序化配信用のＴＬＳ拡張へディスパッチする（Ｓ１５）。非順序化配信に対しては（Ｓ１５）、各レコードには、シーケンス番号（ＳＱＮ）アサイナーによって明確なシーケンス番号が割り当てられることが好ましい。各レコードは、続いて、受信機へ送信される（Ｓ１６）。
受信側２００では、ＴＬＳが、ＳＣＴＰの受信機能からＳＣＴＰメッセージを受信する場合（Ｓ１７）、レコードヘッダのタイプフィールドに従って、レコードのディスパッチャ（Ｓ１８）は、データレコードを、レガシーのＴＬＳプロトコルスタックへディスパッチする（Ｓ１９）、あるいはＳＣＴＰ非順序化配信用のＴＬＳ拡張へディスパッチする（Ｓ２０）。非順序化配信レコード（Ｓ２０）に対しては、シーケンス番号は、ＳＱＮ抽出部によって抽出され、セキュリティ処理がＳＱＮセキュリティ処理モジュールによって実行される。このＳＱＮ処理モジュールは、例えば、再生保護、完全性保護及びデータ損失保護の少なくとも１つを含むセキュリティ機能を含んでいることが好ましい。続いて、レコードがアプリケーションへ与えられる（Ｓ２１）。
順序化配信シーケンス空間では、データレコードは、それらが送信される順序と同一の順序で到来するので、そのデータレコードは、明確なシーケンス番号スキームを使用する通常のＴＬＳ接続によって適切に処理することができる。
ＳＣＴＰ非順序化配信用のＴＬＳ拡張を参照すると、レコード到来は、通常は、信頼性がある。しかしながら、非順序化レコードについては、それらが送信される順序と同一の順序で到来する必要はない。非順序化配信レコードに対して完全保護を実行するためには、ＴＬＳレコードのフォーマットは変更されるべきであり、そうすることで、これは、明確なシーケンス番号を含められる（これは、レコード単位でシーケンス番号が単調増加する順序化配信シーケンスと比較して、ここでは、そのシーケンス番号は、通信エンドポイントで確認可能な状態で維持することができる）。２つのタイプのレコードのヘッダ間で要求される違いは、非順序化レコードは、明示的なシーケンス番号を搬送することである。
再生保護は、再生保護チェックを実行するために受け入れられている処理を使用して、シーケンス番号情報に基づいて実行されることが好ましい。単純なサービス拒否攻撃を回避するために、好ましくは、再生保護情報に完全性保護が含められるべきである。ＭＡＣ（図８参照）がシーケンス番号を介して算出される場合、通常キー化ＭＡＣ検証（ordinary keyed MAC verification）を使用することによって、この情報に対する完全性保護がなされる。攻撃者がシーケンス番号（再生保護情報）を変更する場合、ＭＡＣを検証することはできないが、プロトコルは適切な動作を行うことになる。
非順序化シーケンス内のシーケンス番号間のギャップは大きいので、固定サイズの再生ウィンドウ（例、ＥＳＰ）を維持することは実現不可能な場合がある。概念リストに代えて、例えば、リンク化リストの形式では、受信レコードにギャップを含めることで、より効果的なメモリ利用を維持することができる。この概念リストは、信頼性のある再生保護を実行するために使用される。再生保護実装を使用すべきかの決定は、例えば、ストリーム内の非順序化レコードと順序化レコードの分布に依存して行うことができる。この決定は、この分布の事前知識に基づくことが好ましく、これは、アプリケーション行動の知識から推定することができる。
図１０は、本発明の実施形態に従って、受信しているレコードの間隔のリストを受信機がどのようにして維持しているかを示している（ペア（対）の１つ目の番号は、間隔の下限を示していて、ペアの２つ目の番号は間隔の上限を示している）。また、それらが完了する場合に、その間隔をどのようにしてマージすることができるかを示している（レコード３とレコード２が到達する場合になにが発生しているかがわかる）。換言すれば、図１０は、どのレコードが確認されるかの経過を受信機が追跡する、非順序化配信に対する再生リストの例を示している。
別の構成は、受信機が受信していないレコードのリストを保持することである。これは、受信機がどのレコードをまだ確認していないかを示す、再生リストの例を示す図１１で示される。図１１では、ＩＮＦは、概念的な無限大、あるいは最大許容シーケンス番号を示している。最大シーケンス番号は、モジューロ方法で説明することができる。例えば、シーケンス番号が０ｘｆｆｆｅで開始し、かつシーケンス番号フィールドが１６ビット幅である場合、「最大」シーケンス番号は、例えば、０ｘｆｆｆｄ、即ち、モジューロ２＾１６周辺の数となる。
データ損失保護に対して、セキュリティプロトコル接続の切断用の切断メッセージは、一般的には、送信する非順序化データメッセージの最終シーケンス番号を含んでいて、また、非順序化レコード空間で送信されるすべてのレコードの信頼性のある受信は、その切断メッセージの最終シーケンス番号に基づいて検出することができる。このシーケンス番号のセットは、一般的には順序化セット（順序付けされたセット）であり、また、この最終シーケンス番号は、その順序における「最大」要素であることが理解されるべきである。
ＴＬＳでは、切断メッセージは、典型的には、終了アラートメッセージとして参照される。「ＴＬＳ」コンテキストにおいてデータ損失の検出を実行するために、「ＴＬＳ」接続が終了される直前に、各通信エンドポイントから送信される終了アラートメッセージは、図１２に示されるように、送信された非順序化配信メッセージの「最大」シーケンス番号を含んでいるべきである。ここで、図１２は、非順序化空間の最大シーケンス番号を含む順序化空間で、終了アラートメッセージを送信する例を示している。これは、エンドポイントに到達していない非順序化パケットが存在しないことを確認させることを、エンドポイントに対して要求される。例えば、エンドポイントＡが、エンドポイントＢ（図の５）によって送信される最大非順序化シーケンス番号を含む終了アラートを受信する場合、これは、非順序化シーケンスで１から５へすべてのレコードを受信するまで、接続を切断すべきでないことを知ることになる。
図１３は、本発明の実施形態に従う、受信機の関連部分を示すブロック図である。この例では、受信機２００は、基本的には、メッセージ受信部２１０、ディスパッチャ２２０、順序化配信保護用モジュール２３０、非順序化配信保護用モジュール２４０及びアプリケーションモジュール２５０を備えている。メッセージ受信部２１０は、ＳＣＴＰのようなトランスポートプロトコルのメッセージ受信機能を含み、また、データメッセージあるいはレコードのバッファリングを可能にする。メッセージ受信部は、メッセージタイプをチェックするディスパッチャ２２０へデータメッセージを転送する。ディスパッチャは、好ましくは、データメッセージのヘッダのタイプフィールドに従って、データメッセージを、順序化配信（非）保護用モジュール２３０あるいは非順序化配信（非）保護用モジュール２４０へディスパッチする。例えば、順序化配信モジュール２３０は、レガシーのＴＬＳプロトコルスタックを実現することができ、また、非順序化配信モジュール２４０は、非順序化配信のためのＴＬＳ拡張を実現することができる。好ましくは、モジュール２４０は、シーケンス番号抽出部２４２、完全性チェッカ２４４（例えば、ＭＡＣ検証）、再生チェック２４６及び関係再生リスト記憶部２４８を含んでいる。データメッセージが一旦処理されると、それらは、アプリケーション２５０へ転送される。
まとめると、トランスポートプロトコルの状態は、非順序化配信と順序化配信とに分離される。しかしながら、今日の現在のセキュリティプロトコルは、この分離を実行することができない。それゆえ、本発明の基本概念は、図１４に示されるように、セキュリティプロトコルを拡張して、この分離を上位レイヤでも可能にすることである。図１４は、ＴＬＳセキュリティプロトコルとＳＣＴＰトランスポートプロトコルの組み合わせ例に対して、セキュリティプロトコルとトランスポートプロトコルの両方での順序化配信と非順序化配信との分離を示している。重要な点は、セキュリティプロトコルレイヤへアクセスするために１つ以上のエントリポイントが使用されるかどうかに関わらず、順序化配信を使用するデータメッセージと、非順序化配信を使用するデータメッセージとを別々に処理することである。これは、２つの異なるメッセージタイプが、少なくともセキュリティ処理中に、セキュリティプロトコルレイヤ上で分離されなければならない、あるいは分離が維持されなければならないことを示すものである。また、セキュリティプロトコルと信頼性のあるトランスポートプロトコルの他の組み合わせを用いることができることは容易に理解される。
非順序化配信に対するＴＬＳ拡張ようなセキュリティプロトコル拡張と、レガシーのＴＬＳのような対応するレガシーセキュリティプロトコル間の違いは、非順序化配信用のセキュリティプロトコル拡張（図９及び図１４参照）が、非順序化配信を取り扱うために必要とされるセキュリティ処理を実行することである。例示のように、セキュリティプロトコル拡張は、以下のように、
・レコードで搬送される明確なシーケンス番号を処理し、
・このシーケンス番号に基づいて再生保護を実行する（潜在的には、例えば、レガシーのＴＬＳにおけるスキームとは異なる、ハンドシェーク中にスキームを決定することができるスキームを使用して）
ように構成されることが好ましい。
上述の実施形態は単なる例示であり、本発明がそれに限定されるべきものでないことが理解されるべきである。本明細書で開示され、かつ定義される原理の基礎となる構成を維持する、更なる変形、変更及び改善は、本発明の範囲内である。
文献
［１］アール．スチュアート等、「ストリーム制御送信プロトコル」、ＲＦＣ２９６０、ＩＥＴＦ、２０００年１０月
［２］ジェイ．ローゼンバルグ等、「トランスポート用セッション開始プロトコル（ＳＩＰ）としてのストリーム制御送信プロトコル（ＳＣＴＰ）」、インターネット草稿、ＩＥＴＦ、２００５年１月
［３］３ＧＰＰ ＴＳ．３３．２２０：「汎用認証アーキテクチャ（ＧＡＡ）；汎用ブートストラップアーキテクチャ（リリース６）」、２００４年７月
［４］エス．ケント及びアール．アトキンソン、「ＩＰ認証ヘッダ」、ＲＦＣ２４０２、ＩＥＴＦ、１９９８年１１月
［５］エス．ケント及びアール．アトキンソン、「ＩＰカプセル化セキュリティペイロード（ＥＳＰ）」、ＲＦＣ２４０６、ＩＥＴＦ、１９９８年１１月
［６］ティー．ディレクス及びシー．アレン、「ＴＬＳプロトコル−バージョン１．０」、ＲＦＣ２２４６、ＩＥＴＦ、１９９９年１月
［７］エイ．ジュンマイヤ等、「トランスポートレイヤセキュリティオーバストリーム制御送信プロトコル」、ＲＦＣ３４３６、ＩＥＴＦ、２００２年１２月
［８］イー．レスコラ、エヌ．モダドゥグ、「データグラムトランスポートレイヤセキュリティ」、インターネット草稿、２００４年６月
ＳＣＴＰ非順序化配信を示す図である。 トランスポートプロトコルとしてＳＣＴＰを使用して、シグナリングメッセージを交換するＳＩＰプロキシを示す図である。 ＤＩＡＭＥＴＥＲサーバを使用する場合の典型的な認証を示す図である。 従来のＴＬＳデータレコードのフォーマットを示す図である。 従来技術のＳＣＴＰサービスのＴＬＳサポートを示す図である。 本発明の実施形態に従う信頼性のあるトランスポートプロトコル用のデータセキュリティを改善する方法のフロー図である。 本発明の実施形態に従う非順序化配信レコード用のシーケンス空間の例を示す図である。 本発明の実施形態に従う（ＳＣＴＰ）非順序化配信用の新規のレコードヘッダの例を示す図である。 ＴＬＳとＳＣＴＰを参照する本発明の実施形態に従うデータフロー例を示す図である。 本発明の実施形態に従う、受信しているレコードの間隔のリストを受信機がどのようにして保持するかを示す図である。 本発明の実施形態に従う、受信機がどのレコードをまだ確認していないかを示す再生リストの例を示す図である。 非順序化空間の最大シーケンス番号を含む順序化空間で、終了アラートメッセージを送信する例を示す図である。 本発明の実施形態に従う受信機の関連部分を示すブロック図である。 ＴＬＳセキュリティプロトコルとＳＣＴＰトランスポートプロトコルの組み合わせ例に対し、セキュリティプロトコルとトランスポートプロトコルの両方における、順序化配信と非順序化配信との分離を示す図である。

Claims (23)

  1. データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに対するデータセキュリティを提供する方法であって、
    前記トランスポートプロトコルの上位で動作するセキュリティプロトコルで順序化配信データと非順序化配信データとを分離し、
    前記セキュリティプロトコルで、順序化配信データ用の第１タイプのセキュリティ処理と、非順序化配信データ用の第２タイプのセキュリティ処理を実行する
    ことを特徴とする方法。
  2. 前記信頼性のあるトンラスポートプロトコルは、ＳＣＴＰ（ストリーム制御送信プロトコル）である
    ことを特徴とする請求項１に記載の方法。
  3. 前記セキュリティプロトコルは、非順序化配信用のセキュリティ処理拡張を有するＴＬＳ（トランスポートレイヤセキュリティ）に基づいている
    ことを特徴とする請求項１または２に記載の方法。
  4. 前記信頼性のあるトランスポートプロトコルは、ＳＣＴＰ（ストリーム制御送信プロトコル）であり、
    前記セキュリティプロトコルは、ＳＣＴＰ順序化配信用の基本セキュリティ処理と非順序化配信用のＳＣＴＰセキュリティ処理拡張を有するＴＬＳ（トランスポートレイヤセキュリティ）に基づいている
    ことを特徴とする請求項１に記載の方法。
  5. 前記セキュリティ処理拡張の使用は、セッションセットアップ中にネゴシエートされる
    ことを特徴とする請求項４に記載の方法。
  6. セキュアデータストリーム内の順序化配信を使用するデータメッセージと非順序化配信を使用するデータメッセージとは、セキュリティプロトコルレイヤ上で２つのメッセージシーケンス空間に分離され、
    データセキュリティ処理が、前記２つのメッセージシーケンス空間で別々に実行される
    ことを特徴とする請求項１に記載の方法。
  7. 非順序化配信メッセージ用の前記セキュリティ処理は、非順序化配信メッセージによって搬送される明確なシーケンス番号の処理に基づいている
    ことを特徴とする請求項６に記載の方法。
  8. 非順序化配信メッセージは、非順序化メッセージに向けられている専用メッセージタイプの導入によって識別され、
    前記非順序化メッセージのそれぞれは、非順序化メッセージに向けられている専用シーケンス番号空間から割り当てられる明確なシーケンス番号を有している
    ことを特徴とする請求項６に記載の方法。
  9. 受信されている前記非順序化メッセージの概念リスト、あるいは受信されていない前記非順序化メッセージのその概念リストの代替リストが、非順序化配信メッセージに対する再生保護を実行するために保持される
    ことを特徴とする請求項７または８に記載の方法。
  10. セキュリティプロトコル接続の切断用の切断メッセージは、送信済の非順序化データメッセージの最終シーケンス番号を含み、
    非順序化レコード空間内の送信済のすべてのレコードの信頼性のある受信は、前記切断メッセージの最終シーケンス番号に基づいて検出される
    ことを特徴とする請求項７または８に記載の方法。
  11. データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに対するデータセキュリティを提供するシステムであって、
    前記トランスポートプロトコルの上位で動作するセキュリティプロトコルで順序化配信データと非順序化配信データとを分離する手段と、
    前記セキュリティプロトコルで、順序化配信データ用の第１タイプのセキュリティ処理と、非順序化配信データ用の第２タイプのセキュリティ処理を実行する手段と
    を備えることを特徴とするシステム。
  12. 前記信頼性のあるトランスポートプロトコルは、ＳＣＴＰ（ストリーム制御送信プロトコル）であり、
    前記セキュリティプロトコルは、ＳＣＴＰ順序化配信用の基本セキュリティ処理とＳＣＴＰ非順序化配信用のセキュリティ処理拡張を有するＴＬＳ（トランスポートレイヤセキュリティ）に基づいている
    ことを特徴とする請求項１１に記載のシステム。
  13. データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに基づいて動作するように構成されている受信機であって、
    前記トランスポートプロトコルの上位において、セキュリティプロトコルで順序化配信データと非順序化配信データとを分離する手段と、
    順序化配信データ用の前記セキュリティプロトコルで、第１タイプのセキュリティ処理を実行する手段と、
    非順序化配信データ用の前記セキュリティプロトコルで、第２タイプのセキュリティ処理を実行する手段と
    を備えることを特徴とする受信機。
  14. 前記受信機は、ＳＣＴＰ（ストリーム制御送信プロトコル）に基づいて動作するように構成され、
    前記受信機は、ＳＣＴＰ順序化配信用の基本ＴＬＳ（トンラスポートレイヤセキュリティ）セキュリティ処理とＳＣＴＰ非順序化配信用のＴＬＳセキュリティ処理拡張を実行するように構成されている
    ことを特徴とする請求項１３に記載の受信機。
  15. 前記分離する手段は、セキュアデータストリーム内の順序化配信を使用するデータメッセージと非順序化配信を使用するデータメッセージとを、セキュリティプロトコルレイヤ上で２つのメッセージシーケンス空間に分離するように構成されている
    ことを特徴とする請求項１３に記載の受信機。
  16. 前記分離する手段は、非順序化メッセージに向けられている専用メッセージタイプの検出に基づいて非順序化配信メッセージを識別するように構成されていて、
    前記非順序化メッセージのそれぞれは、非順序化メッセージに向けられている専用シーケンス番号空間から割り当てられる明確なシーケンス番号を有している
    ことを特徴とする請求項１５に記載の受信機。
  17. 非順序化配信メッセージ用のセキュリティ処理は、非順序化配信メッセージによって搬送される明確なシーケンス番号の処理に基づいている
    ことを特徴とする請求項１５または１６に記載の受信機。
  18. 非順序化配信メッセージに対する再生保護を実行するための、受信されている前記非順序化メッセージの概念リスト、あるいは受信されていない前記非順序化メッセージのその概念リストの代替リストを保持する手段を更に備える
    ことを特徴とする請求項１７に記載の受信機。
  19. データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに基づいて動作するように構成されている送信機であって、
    前記トランスポートプロトコルの上位において、セキュリティプロトコルで順序化配信用に意図されているデータと非順序化配信用に意図されているデータとを分離する手段と、
    データの順序化配信用の前記セキュリティプロトコルで、第１タイプのセキュリティ処理を実行する手段と、
    データの非順序化配信用の前記セキュリティプロトコルで、第２タイプのセキュリティ処理を実行する手段と
    を備えることを特徴とする送信機。
  20. 前記送信機は、ＳＣＴＰ（ストリーム制御送信プロトコル）に基づいて動作するように構成され、
    前記送信機は、ＳＣＴＰ順序化配信用の基本ＴＬＳ（トンラスポートレイヤセキュリティ）セキュリティ処理とＳＣＴＰ非順序化配信用のＴＬＳセキュリティ処理拡張を実行するように構成されている
    ことを特徴とする請求項１９に記載の送信機。
  21. 前記第２タイプのセキュリティ処理を実行する手段は、非順序化データメッセージだけに明確なシーケンス番号を割り当てるように構成されている
    ことを特徴とする請求項１９または２０に記載の送信機。
  22. データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルとともに動作するように構成されているセキュリティプロトコルディスパッチャであって、
    指示されている配信のタイプに従って、順序化配信用の第１タイプのセキュリティプロトコル処理へ、あるいは非順序化配信用の第２タイプのセキュリティプロトコル処理へディスパッチする手段を備える
    ことを特徴とするセキュリティプロトコルディスパッチャ。
  23. 前記ディスパッチする手段は、順序化配信用のデータを基本ＴＬＳ（トンラスポートレイヤセキュリティ）セキュリティ処理へディスパッチし、また、非順序化配信用のデータをＴＬＳセキュリティ処理拡張へディスパッチするように構成されている
    ことを特徴とする請求項２２に記載のセキュリティプロトコルディスパッチャ。
JP2008503989A 2005-03-31 2006-03-09 順不同で配信されるデータの保護 Active JP4903780B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US66659705P 2005-03-31 2005-03-31
US60/666597 2005-03-31
PCT/SE2006/000312 WO2006104438A1 (en) 2005-03-31 2006-03-09 Protection of data delivered out-of-order

Publications (2)

Publication Number Publication Date
JP2008535080A true JP2008535080A (ja) 2008-08-28
JP4903780B2 JP4903780B2 (ja) 2012-03-28

Family

ID=36590174

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008503989A Active JP4903780B2 (ja) 2005-03-31 2006-03-09 順不同で配信されるデータの保護

Country Status (7)

Country Link
US (1) US8352727B2 (ja)
EP (1) EP1867129B1 (ja)
JP (1) JP4903780B2 (ja)
CN (1) CN101151867B (ja)
BR (1) BRPI0608941B1 (ja)
CA (1) CA2597419C (ja)
WO (1) WO2006104438A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8352727B2 (en) 2005-03-31 2013-01-08 Telefonaktiebolaget L M Ericsson (Publ) Protection of data delivered out-of-order
US8488455B2 (en) * 2010-06-21 2013-07-16 Nokia Corporation Method and apparatus for fair scheduling of broadcast services
KR101420784B1 (ko) * 2010-08-06 2014-07-17 엠파이어 테크놀로지 디벨롭먼트 엘엘씨 통신 네트워크 모니터링
US8892695B2 (en) * 2011-09-26 2014-11-18 Samsung Electronics Co., Ltd. Remote input devices
US9237169B2 (en) * 2012-06-01 2016-01-12 Apple Inc. Network stream identification for open FaceTime
US20180376516A1 (en) * 2017-06-21 2018-12-27 Aruba Networks, Inc. Establishing a Datagram Transport Layer Security Connection between Nodes in a Cluster
US11593281B2 (en) * 2019-05-08 2023-02-28 Hewlett Packard Enterprise Development Lp Device supporting ordered and unordered transaction classes
US11792114B2 (en) 2019-05-23 2023-10-17 Hewlett Packard Enterprise Development Lp System and method for facilitating efficient management of non-idempotent operations in a network interface controller (NIC)
US11722561B2 (en) * 2020-12-22 2023-08-08 Telefonaktiebolaget Lm Ericsson (Publ) DTLS/SCTP enhancements for RAN signaling purposes

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003179640A (ja) * 2001-12-10 2003-06-27 Nec Corp ブロードキャスト通信における欠損パケットの補完方式および方法
JP2004080070A (ja) * 2002-08-09 2004-03-11 Nippon Telegr & Teleph Corp <Ntt> データ転送方法及びデータ転送システム並びにコンテンツ配信システム
JP2004180253A (ja) * 2002-09-30 2004-06-24 Sanyo Electric Co Ltd 通信装置、通信方法、およびその方法を利用可能な電話装置、ビデオ電話装置、撮像装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7360075B2 (en) * 2001-02-12 2008-04-15 Aventail Corporation, A Wholly Owned Subsidiary Of Sonicwall, Inc. Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols
US7843968B2 (en) 2002-09-30 2010-11-30 Sanyo Electric Co., Ltd. Communication apparatus and applications thereof
US8352727B2 (en) 2005-03-31 2013-01-08 Telefonaktiebolaget L M Ericsson (Publ) Protection of data delivered out-of-order

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003179640A (ja) * 2001-12-10 2003-06-27 Nec Corp ブロードキャスト通信における欠損パケットの補完方式および方法
JP2004080070A (ja) * 2002-08-09 2004-03-11 Nippon Telegr & Teleph Corp <Ntt> データ転送方法及びデータ転送システム並びにコンテンツ配信システム
JP2004180253A (ja) * 2002-09-30 2004-06-24 Sanyo Electric Co Ltd 通信装置、通信方法、およびその方法を利用可能な電話装置、ビデオ電話装置、撮像装置

Also Published As

Publication number Publication date
JP4903780B2 (ja) 2012-03-28
BRPI0608941A2 (pt) 2010-11-16
CN101151867A (zh) 2008-03-26
EP1867129A1 (en) 2007-12-19
CA2597419A1 (en) 2006-10-05
EP1867129B1 (en) 2016-06-22
US20080307528A1 (en) 2008-12-11
BRPI0608941B1 (pt) 2019-08-20
CA2597419C (en) 2013-07-02
WO2006104438A1 (en) 2006-10-05
CN101151867B (zh) 2012-11-07
US8352727B2 (en) 2013-01-08

Similar Documents

Publication Publication Date Title
JP4903780B2 (ja) 順不同で配信されるデータの保護
US8984268B2 (en) Encrypted record transmission
US6708218B1 (en) IpSec performance enhancement using a hardware-based parallel process
US8799505B2 (en) TCP/IP-based communication system and associated methodology providing an enhanced transport layer protocol
US7710978B2 (en) System and method for traversing a firewall with multimedia communication
US7684414B2 (en) System and method for using performance enhancing proxies with IP-layer encryptors
Iyengar et al. RFC 9000: QUIC: A UDP-based multiplexed and secure transport
WO2016165277A1 (zh) 一种实现IPsec分流的方法和装置
WO2016119464A1 (zh) 一种卫星网络环境下实现tcp传输的方法及相应的网关
US7738459B2 (en) Method, system and apparatus for reliably transmitting packets of an unreliable protocol
EP3994862B1 (en) Packet acknowledgement techniques for improved network traffic management
Hohendorf et al. Secure End-to-End Transport Over SCTP.
Kumar QUIC (Quick UDP Internet Connections)--A Quick Study
JP2003244194A (ja) データ暗号装置及び暗号通信処理方法及びデータ中継装置
CN115699700A (zh) 用于辨别终端与数据服务器之间的消息的方法
WOZNIAK et al. The Need for New Transport Protocols on the INTERNET
Hohendorf et al. Secure end-to-end transport over sctp
Lindskog et al. A comparison of end-to-end security solutions for sctp
Thornburgh RFC 7016: Adobe's Secure Real-Time Media Flow Protocol
Iyengar et al. Minion—an All-Terrain Packet Packhorse to Jump-Start Stalled Internet Transports
Kumar Quick UDP Internet Connections
JP2005348321A (ja) パケット通信装置および方法ならびにプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090223

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110210

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110427

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110801

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111021

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20111219

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120105

R150 Certificate of patent or registration of utility model

Ref document number: 4903780

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

Free format text: PAYMENT UNTIL: 20150113

Year of fee payment: 3

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

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