CN1503527A - 压缩安全协议保护的网际协议分组的方法、设备和系统 - Google Patents
压缩安全协议保护的网际协议分组的方法、设备和系统 Download PDFInfo
- Publication number
- CN1503527A CN1503527A CNA031587429A CN03158742A CN1503527A CN 1503527 A CN1503527 A CN 1503527A CN A031587429 A CNA031587429 A CN A031587429A CN 03158742 A CN03158742 A CN 03158742A CN 1503527 A CN1503527 A CN 1503527A
- Authority
- CN
- China
- Prior art keywords
- compressed
- robust
- leader
- packet header
- header
- 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
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
-
- 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
-
- 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/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
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
一个鲁棒头标压缩方案(“ROHC”)压缩IP安全(“IPSec”)保护的IP分组。更特别的是,ROHC在IPSec加密之前被应用于一个IP分组头标中的一些部分。之后ROHC可以可选地被再次应用于IP分组中未被加密的部分。
Description
技术领域
本发明涉及连网通信领域,并且,更特别的是涉及一项用于将鲁棒头标压缩应用于被加密的网际协议(“IP”)分组的技术。
背景技术
今天各种各样的压缩方案都使得能够压缩和解压缩网络分组头标。许多这样的方案对于在有线的、带宽受限的网络,例如电话网(经调制解调器连接)上传送的分组来说是最优化的。这些方案通常不考虑无线网络特殊的特性,例如有更高的误码率容限以确保成功的分组传送。然而,高误码率可能会大大地降低传统的头标压缩方案的性能。
为了特别针对无线网络的特征,因特网工程任务组(“IETF”)最近开发了一个与无线网络兼容的头标压缩标准。称为鲁棒头标压缩(“ROHC”,IETF RFC 3095,2001年7月)的标准集中于压缩无线网络上多种网络分组的分组头标。迄今为止,“简档(profile)”已被定义用于将ROHC应用于网际协议(“IP”)分组、实时协议(“RTP”)分组、用户数据报协议(“UDP”)分组和传输控制协议(“TCP”)分组。简档是定义如何对多种网络分组实现压缩的方案或协议。
类似于其它压缩方案,ROHC通常被“逐跳地”应用,即在网络上的每个节点处被应用。换句话说,当一个节点接收到一个被压缩的分组头标时,它就解压缩该分组头标、检查头标字段并且重新压缩该分组头标以便传送到该网络上的下一个节点。这些步骤可能在源节点(分组始发处)和目的地节点(分组的最终目的地)之间网络上的每一个节点处实现。
除了压缩以外,安全协议通常也被应用于网络分组。网际协议安全(“IPSec”,IETF RFC 2401,1998年11月)是由IETF开发的一组安全协议,来提供一个网络的IP层上的安全业务。IPSec提供两个用于安全的协议,即IP鉴权头标(“AH”)协议和封装安全净荷(“ESP”)协议。AH可以提供无连接的完整性、数据来源鉴权以及可选的反重放业务,而ESP可以提供加密、有限业务流的保密性、无连接的完整性、数据来源鉴权以及反重放业务。
IPSec保护的IP分组可以以“传送模式”和/或者“隧道模式”被发送。传送模式的传输可以用于例如,在两个对等节点之间,直接将来自一个源节点的一个IP分组安全发送到它的最终目的地节点,而没有任何中间的安全设备。另一方面,隧道模式典型地当来自一个源节点的分组在到达目的地节点之前必须穿过其它的安全设备例如安全网关(包括一个或多个路由器、防火墙以及/或者其它的网络设备)时被使用。隧道模式还可以用于隐藏该分组的流细节,因为对可能截取分组的任何人来说只有隧道入口和出口点才是可见的。
对照ROHC,IPSec不是逐跳地应用的,而是“端到端”地应用。换句话说,一个IPSec保护的分组通常在源节点处被编码并在目的地节点处(或者在隧道模式中的安全网关处)被解码。IETF要求所有符合IPv6(IETF RFC 1883,1995年12月)和MobileIPv6(IETF移动IPv6,因特网草案draft-ietf-mobileip-ipv6-19.txt(正在制定),2002年9月)标准的网络都要使用IPSec,并且建议所有符合IPv4(IETF RFC2401,1998年9月)和MobileIPv4(IETF RFC 3220,2002年1月)标准的网络都使用IPSec。结果是,今天经任何网络发送的IP分组都很有可能被IPSec协议保护。
不幸的是,今天还没有IETF的简档用于将ROHC应用于IPSec保护的分组。换句话说,IPSec保护的IP分组目前可能不能被压缩。不能压缩IPSec保护的IP分组正变成越来越大的问题。当新的IP协议被引入时IP分组的头标在尺寸上增加了。例如,IPv6标准几乎增加了百分之五十的IP分组的头标尺寸。另外,用于确保符合IPv4的网络和符合IPv6的网络之间的兼容性而引入“v4-v6隧道”的概念已经给IP分组的头标增加了相当大的开销。移动IP协议也引入了额外的IP分组头标,因此也促使IP分组尺寸的膨胀。
结果是,需要能够压缩IP分组,并且更特别的是能够压缩IPSec保护的IP分组。IETF最近讨论了使用一个叫做“IPComp”的压缩方案来使得能够对IPSec保护的IP分组进行头标压缩的可能性。然而,IPComp受到许多缺点的困扰。最重要的是,IPComp是一个通用压缩方案,被设计用于数据压缩。因此,与ROHC相比,IPComp只给分组头标的压缩提供了有限的压缩增益,ROHC对于分组头标的压缩来说是最优化的并且可以获得80%和/或者90%之间的压缩效率。在压缩效率上的这个不同还部分地是由于这两种压缩方案的固有特征。IPComp是一个“无状态的”方案,即,它单独地压缩和解压缩每一个IP分组,与其它分组没有任何联系。相反,ROHC是一个“有状态的”压缩方案,它更复杂,因为它会保留与每一个IP分组有关的额外的信息,而且也可获得一个更高的压缩程度。
附图说明
本发明通过例子来被说明并且不受附图中各图的限制,其中相似的参考指示类似的组成部分,并且其中:
图-1举例说明了一种经一个网络发送一个IP分组的已知的方法;
图-2是一个举例说明了将ROHC应用于一个IP分组的已知方法的分组流程图;
图-3是一个举例说明了将IPSec应用于一个IP分组的已知方法的分组流程图;
图-4是一个举例说明本发明其中一个实施方案的分组流程图;
图-5举例说明了按照本发明实施方案的一个系统(“系统500”)。
具体实施方式
本发明的实施方案将鲁棒头标压缩应用于被加密的网络分组。为了本说明书的目的,对鲁棒头标压缩的引用包括ROHC或其它类似的逐跳的压缩方案,而对IPSec的引用包括IPSec、其它具有与IPSec类似的特征的网络协议,例如其它的网络安全协议以及/或者其它的端到端的网络协议。另外,在本说明书中对本发明“其中一个实施方案”或者本发明的“一个实施方案”的引用意味着结合所述实施方案被描述的一个特定的特点、结构或特征被包括在本发明的至少其中一个实施方案中。这样,贯穿整个说明书在多处地方出现的短语“在其中一个实施方案中”、“按照其中一个实施方案”或者诸如此类的短语不一定全都指的是同一个实施方案。
图-1举例说明了一种经一个网络(“网络100”)发送一个IP分组的已知的方法。正如所示例的,IP分组可能在源节点101处始发并经网络100被发送到目的地节点102。然而,所述IP分组不可能直接从源节点101到达目的地节点102。而是在一个典型的网络例如网络100中,该IP分组可能经一个或多个中间节点,就像在图-1中被举例说明的IN103、IN104、IN105、IN106和IN107,而被路由。
图-2是一个举例说明了在不加密的情况下将ROHC应用于经网络100从源节点101发送到目的地节点102的IP分组(“IP分组200”)的已知方法的分组流程图。ROHC依靠IP分组的多个固有特征来获得它的压缩增益。最重要的是,用于一个特定的IP会话的IP分组头标通常包括在每一个分组中冗余的以及/或者高度可预测的信息。例如,在一个特定的IP会话中,一个分组的源和目的地节点信息保持静态(即,不管在每一个分组中发送的新数据如何,在一个会话的持续期间该分组总是在源节点处始发并在目的地节点处结束)。这样,经网络被发送的每一个IP分组在该IP会话的持续期间在它的头标字段中重复相同信息的源和目的地信息。正如对那些本领域的普通技术人员来说很明显的,在分组头标中多种其它类型的会话信息(例如,端口地址和会话ID)也可能是冗余的并且/或者是高度可预测的。
除其他之外,ROHC提供了一种方法,通过该方法该冗余的并且/或者是高度可预测的头标字段信息可以用上下文ID来代替。此后,可以改而发送该头标的上下文ID,而不必在一个会话中随每一个IP分组发送该冗余的并且/或者是高度可预测的头标信息。这就产生了一个小得多的或者是“被压缩的”分组。在目的地节点处一旦接收到该分组,该节点就通过在一张表中查找该上下文ID来解压缩该分组,所述表将上下文ID与原始信息相映射。目的地节点可以因此恢复该原始的分组。发送上下文ID而不是重复发送冗余的并且/或者是高度可预测的信息使得ROHC能够获得相当大的头标压缩增益。
正如在图-2中举例说明的,在一个实施方案中,IP分组200可能包括以下头标字段:IP头标201、扩展头标202、内头标203、传送头标204以及净荷205。对那些本领域的普通技术人员来说很明显:IP头标201、扩展头标202、内头标203和传送头标204代表一个IP分组中典型的头标字段,而ROHC的应用并不只局限于这种字段。IP头标201包括与IP分组200的源节点和目的地节点有关的信息。扩展头标202包括例如移动IPv4和/或者v6头标的头标。内头标203包括可选的内IP头标和其它可选的扩展头标。传送头标204包括TCP、UDP、RTP、流控制传输协议(“SCTP”)和/或者其它传送协议头标(只有目的地才能理解)。净荷205包括从源节点101被发送到目的地节点102的数据。
在源节点101处,ROHC可以被应用于IP分组200的头标字段,在这种情况下,为IP头标201、扩展头标202、内头标203和传送头标204。正如所示例的,这就产生了被压缩的IP分组206,它包括被压缩的头标207和净荷205。被压缩的IP分组206可能从源节点101被发送到IN103。IN103接收到被压缩的IP分组206,解压缩被压缩的头标207并检查解压缩的头标字段。一旦IN103确定IP分组200的目的地,之后它就可以将IP头标201、扩展头标202、内头标203和传送头标204重新压缩成被压缩的IP分组206并将被压缩的IP分组206发送到网络上的下一个中间节点,即IN104。上述过程在IN104处以及其它中间节点(IN105、IN106和IN107)处被重复直到IP分组200在目的地节点102处被接收到。
图-3是一个举例说明了今天IPSec在没有ROHC的情况下是如何被应用于经网络100从源节点101被发送到目的地节点102的一个IP分组的分组流程图。正如所示例的,在一个实施方案中,IP分组300包括以下字段:IP头标301、扩展头标302、内头标303、传送头标304和净荷305。再一次,对那些本领域的普通技术人员来说很明显:IP头标301、扩展头标302、内头标303和传送头标304代表一个IP分组中典型的头标字段,而IPSec协议并不只局限于这种字段。
正如在图-3中举例说明的,一个IPSec协议,例如ESP,可以被应用于IP分组300,以便加密该分组。这个加密就产生了一个被加到该分组上的ESP头标(“ESP头标306”),同时扩展头标302、内头标303、传送头标304和净荷305全部被加密,就产生了被加密的净荷+头标307。被加密的净荷+头标307、IP头标301和ESP头标306一起组成被加密的IP分组308,之后它可以从源节点101经中间节点(IN103、IN104、IN105、IN106和IN107)到达目的地节点102。在目的地节点102上,被加密的IP分组308可以被解密(删除ESP头标306并解密分组中被加密的部分),这样就恢复了IP分组300。
基于图-2和图-3,对那些本领域的普通技术人员来说很明显,这两种方案目前是不兼容的因为加密有效地阻止了ROHC,使其不能在源节点101和目的地节点102之间的每一个节点处压缩和解压缩IP分组的大部分头标。更特别的是,在IPSec保护的IP分组中,头标字段通常在源节点101处被加密并且可能只由目的地节点102解密。因为大部分头标字段被加密,所以ROHC可能不被逐跳地应用于被加密的分组部分。相反,正如从图-3的示例中很明显示出的那样,ROHC可能只被应用于未被加密的头标字段(IP头标301和ESP头标306),这就提供了只是最小的压缩增益。所以需要能够以提供增加的压缩增益的这样一种方式来压缩IPSec保护的IP分组。
本发明的实施方案描述了一种方案,通过它ROHC可以被应用于IPSec保护的IP分组。按照本发明的其中一个实施方案,ROHC可以在加密之前被应用于一个IP分组头标中的一些部分,之后ROHC可以可选地被再次应用于未被压缩的、未被加密的分组头标。之后安全的、被压缩的IP分组可以从一个源节点经多个中间节点被发送到一个目的地节点。换句话说,按照本发明的实施方案,ROHC可以分阶段地被应用于IPSec保护的IP分组的全部头标,这样就最大化了压缩增益。
图-4更详细地举例说明了本发明的一个实施方案。再一次,IP分组400从源节点101经多个中间节点(IN103、IN104、IN105、IN106和IN107)被发送到目的地节点102。然而,按照其中一个实施方案,ROHC和IPSec协议在传输之前被应用于该分组。更特别的是,IP分组400初始包括以下字段:IP头标401、扩展头标402、内头标403、传送头标404和净荷405。对那些本领域的普通技术人员来说很明显:IP头标401、扩展头标402、内头标403和传送头标404代表一个IP分组中典型的头标字段,而本发明的实施方案并不只局限于这种字段。
按照其中一个实施方案,在450中,ROHC被应用于内头标403和传送头标404,就产生了一个端到端的被压缩的头标字段(“e2e被压缩的头标406”)。e2e被压缩的头标406包括只由目的地节点102使用的信息,即该信息对分组穿越源节点101和目的地节点102之间的任何中间节点来说是不必的。e2e被压缩的头标406,连同IP头标401、扩展头标402和净荷405一起组成端到端被压缩的IP分组407。接下来,在451中,端到端被压缩的IP分组407按照一个IPSec协议例如ESP被加密,这将一个ESP头标字段(“ESP头标408”)加到IP分组400上,并且从e2e被压缩的头标406和净荷405生成被加密的分组(“被加密的分组409”)。现在被加密的端到端被压缩的IP分组407(“端到端被压缩的加密IP分组410”)包括IP头标401、扩展头标402、ESP头标408和被加密的分组409。
可选地,按照本发明的其中一个实施方案,ROHC可以被再次应用,以便最大化该IP分组400的压缩。ROHC的这种应用可能类似于上面依照图-2描述的过程。更特别的是,在452中,ROHC可以被应用于端到端被压缩的加密IP分组410,这导致了IP头标401、扩展头标402和ESP头标408被压缩成逐跳被压缩的头标411。按照本发明的一个实施方案,最终的分组,即逐跳被压缩的加密分组412会让对于在每跳处压缩和解压缩分组必需的分组头标不被加密。
这样,例如,当端到端被压缩的加密IP分组410从源节点101被发送到第一个中间节点IN103时,在453中IN103可以将逐跳被压缩的头标411解压缩成IP头标401、扩展头标402和ESP头标408,确定逐跳被压缩的加密IP分组412的目的地,之后再一次重新压缩(即,将ROHC应用于)IP头标401、扩展头标402和ESP头标408。之后,产生的逐跳被压缩的加密IP分组412可从IN103被发送到下一个中间节点,IN104。在453中,在IN104处一旦接收到逐跳被压缩的头标411,它就可以被解压缩成IP头标401、扩展头标402和ESP头标408。这个过程实质上恢复了端到端被压缩的加密IP分组410。这个解密使得IN104能够确定端到端被压缩的加密IP分组410的下一个目的地。之后IN104重复452以便生成逐跳被压缩的加密IP分组412并且将该分组发送到IN105。这个过程可以持续,一直到逐跳被压缩的加密IP分组412在目的地节点102处被接收到。
如果上面描述的可选的ROHC应用被实现的话,那么当逐跳被压缩的加密IP分组412在目的地节点102处被接收到时,它首先在453中被解压缩(就象在网络上每一个中间节点处所发生的那样)以便恢复端到端被压缩的加密IP分组410。然而,之后在目的地节点102处,在454中,端到端被压缩的加密IP分组410可以被解密,即删除ESP头标408并将被加密的分组409恢复成e2e被压缩的头标406和净荷405。之后在455处,e2e被压缩的头标406可以被解压缩,这进而又恢复内头标403和传送头标404。以这种方式,IP分组400在目的地节点102处被恢复。
本发明的实施方案可以使得ROHC能够可选地被应用于整个IP分组。例如,在一个场景中,其中IPv4的IP分组在IPv6的网络内被“用隧道传输”,ROHC可以在将IPv6的头标加到分组之前被应用于整个IPv4的IP分组。因此被压缩的IPv4的IP分组可以作为IPv6的IP分组的净荷,并且按照本发明的实施方案,ROHC可以在IPv6分组被加密之前被再次应用于IPv6分组。所以在本发明的实施方案中,ROHC对IP分组的分层的(或者重复的)应用可以大大地增加压缩效率。
图-5举例说明了按照本发明实施方案的一个系统(“系统500”)。对那些本领域的普通技术人员来说很明显:系统500的各个组成部分可以用硬件、软件、固件以及/或者其中的任何组合来实现。正如所示例的,系统500包括在源节点101处的压缩单元501、加密单元502和压缩单元503,以及在目的地节点102处的解压缩单元504、解密单元505和解压缩单元506。下面的描述假定这个系统用于实现在上面图-4中描述的本发明的实施方案。
按照其中一个实施方案,在源节点101处,压缩单元501将ROHC应用于IP分组400的头标字段(特别是应用于内头标403和传送头标404),就产生了一个端到端被压缩的头标字段(“e2e被压缩的头标406”)。e2e被压缩的头标406,连同IP头标401、扩展头标403和净荷405一起组成端到端被压缩的IP分组407。接下来,加密单元502按照一个IPSec协议例如ESP,加密端到端被压缩的IP分组407,将一个ESP头标字段(“ESP头标408”)加到IP分组400上,并从e2e被压缩的头标406和净荷405生成被加密的分组(“被加密的分组409”)。被加密的端到端被压缩的IP分组407(“端到端被压缩的加密IP分组410”)现在包括IP头标401、扩展头标402、ESP头标408和被加密的分组409。
系统500可以可选地包括压缩单元503。对那些本领域的普通技术人员来说很明显压缩单元503是与压缩单元501一样的单元,或者是一个单独的独立单元。在任一种情况下,按照本发明的其中一个实施方案,压缩单元503可以再次应用ROHC,这次是应用到端到端被压缩的加密IP分组410,以便最大化IP分组400的压缩。这种ROHC的应用导致IP头标401、扩展头标402和ESP头标408被压缩成逐跳被压缩的头标411。这就产生了逐跳被压缩的加密分组412。
逐跳被压缩的IP分组412被发送(经过各个中间节点)到目的地节点102。一旦接收到逐跳被压缩的IP分组412,它就被解压缩单元504解压缩。正如对那些本领域的普通技术人员来说很明显的那样,如果在源节点101处可选的压缩过程被压缩单元503实现,那么解压缩单元504就只实现这个动作。这个解压缩恢复端到端被压缩的加密IP分组410。之后解密单元505解密端到端被压缩的加密IP分组410,从而删除ESP头标408并将被加密的分组409恢复成e2e被压缩的头标406和净荷405。之后解压缩单元506可以解压缩e2e被压缩的头标406,这进而又恢复内头标403和传送头标404。以这种方式,IP分组400在目的地节点102处被恢复。
本发明的实施方案可以在多个数据处理设备上实现。对那些本领域的普通技术人员来说很明显:这些数据处理设备可以包括各种软件,并且可以包括设备,例如大型计算机、工作站、个人计算机、膝上型电脑、便携式手持电脑、PDA以及/或者蜂窝电话。
按照本发明的一个实施方案,所述数据处理设备是一个可以包括各种能够执行指令以便实现本发明一个实施方案的组件的机器。正如在这个说明书中所使用的,一个“机器”包括,但是并不局限于,任何带有一个或多个处理器的数据处理设备。该机器可以,例如,包括并且/或者被耦合到至少一个机器可访问的媒介。正如在这个说明书中所使用的,一个机器可访问的媒介包括以一个机器可访问的任何形式来存储和/或者发送信息的任何机制,所述机器可访问的媒介包括但是并不局限于,可记录的/不可记录的媒介(例如只读存储器(ROM),随机存取存储器(RAM),磁盘存储媒介、光存储媒介和闪存设备),同时还有电的、光的、声的或者被传播信号的其它形式(例如载波、红外信号以及数字信号)。
按照一个实施方案,一个机器以及机器可访问的媒介可以通过一个桥/存储控制器而通信地耦合,并且该机器的处理器可能能够执行存储在该机器可访问的媒介中的指令。所述桥/存储控制器可以与一个图形控制器相耦合,并且所述图形控制器可以控制一个显示设备上显示数据的输出。所述桥/存储控制器可以与一个或多个总线相耦合。一个主机总线的主机控制器例如一个通用串行总线(“USB”)主机控制器可以与该总线(多条总线)相耦合并且多个设备可以与USB相耦合。例如,用户输入设备(比如一个键盘和鼠标)可以被包括用于提供输入数据。
在前述说明书中,本发明已经通过参考其特定示例的实施方案被描述。然而,将应理解,可对其进行多种修改和改变而不偏离在附加的权利要求中阐明的更广泛的精神和范围。本说明书及附图相应地被认为具有示例的意义而不是限制的意义。
Claims (30)
1.一种保护和压缩一个网络分组的方法,包括:
将一个第一鲁棒头标压缩方案应用于一个第一分组头标从而生成一个第一端到端被压缩的分组头标;以及
将所述第一端到端被压缩的分组头标和一个净荷加密从而生成一个安全的被压缩的网络分组。
2.按照权利要求1中的方法还包括:将一个第二鲁棒头标压缩方案应用于一个第二头标从而生成一个第二逐跳被压缩的分组头标。
3.按照权利要求2中的方法,其中所述第一鲁棒头标压缩方案和第二鲁棒头标压缩方案是鲁棒头标压缩(“ROHC”)。
4.按照权利要求1中的方法,其中加密所述第一端到端被压缩的分组头标包括将一个IP安全(“IPSec”)协议应用于所述第一端到端被压缩的分组头标。
5.一种解压缩一个安全的被压缩的网络分组的方法,包括:
接收包括一个第一端到端被压缩的分组头标和一个净荷的所述安全的被压缩的网络分组;
解密所述安全的被压缩的网络分组从而恢复所述第一端到端被压缩的分组头标和所述净荷;以及
将一个第一鲁棒头标解压缩方案应用于所述第一端到端被压缩的分组头标从而恢复一个第一分组头标。
6.按照权利要求5中的方法,其中所述安全的网络分组还包括一个第二逐跳被压缩的分组头标。
7.按照权利要求6中的方法还包括将一个第二鲁棒头标解压缩方案应用于所述第二个逐跳被压缩的分组头标从而恢复一个第二分组头标。
8.按照权利要求7中的方法,其中所述第一鲁棒头标解压缩方案和第二个鲁棒头标解压缩方案是鲁棒头标压缩(“ROHC”)。
9.一种用于保护和压缩一个网络分组的设备,包括:
一个鲁棒头标压缩单元,它能够将一个第一鲁棒头标压缩方案应用于一个第一分组头标从而生成一个第一端到端被压缩的分组头标;以及
一个加密单元能够将所述第一端到端被压缩的分组头标和一个净荷加密从而生成一个安全的被压缩的网络分组。
10.按照权利要求9中的设备还包括一个第二鲁棒头标压缩单元,它能够压缩一个第二分组头标从而生成一个第二逐跳被压缩的分组头标。
11.按照权利要求10中的设备,其中所述第一鲁棒头标压缩方案和第二个鲁棒头标压缩方案是鲁棒头标压缩(“ROHC”)。
12.按照权利要求9中的设备,其中所述加密单元能够应用一个IP安全(“IPSec”)协议。
13.一种用于解压缩一个安全的被压缩的网络分组的设备,包括:
一个解密单元,它能够解密所述安全的被压缩的网络分组头标从而恢复一个第一端到端被压缩的分组头标和一个净荷;以及
一个解压缩单元,它能够将一个第一鲁棒头标解压缩方案应用于所述第一端到端被压缩的分组头标从而恢复一个第一分组头标。
14.按照权利要求13中的设备还包括一个第二鲁棒头标解压缩单元,它能够解压缩一个第二逐跳被压缩的分组头标从而恢复一个第二分组头标。
15.按照权利要求14中的设备,其中所述第一鲁棒头标解压缩方案和第二个鲁棒头标解压缩方案是鲁棒头标压缩(“ROHC”)。
16.一种包括一个在其上已经存储有指令的机器可访问的媒介的产品,当该指令由一个机器执行时,会使该机器:
将一个第一鲁棒头标压缩方案应用于一个第一分组头标从而生成一个第一端到端被压缩的分组头标;以及
将所述第一端到端被压缩的分组头标和一个净荷加密从而生成一个安全的被压缩的网络分组。
17.按照权利要求16中的产品还包括指令使得所述机器将一个第二鲁棒头标压缩方案应用于一个第二头标从而生成一个第二逐跳被压缩的分组头标。
18.按照权利要求17中的产品,其中所述第一鲁棒头标压缩方案和第二鲁棒头标压缩方案是鲁棒头标压缩(“ROHC”)。
19.按照权利要求16中的产品,其中使得所述机器加密所述第一端到端被压缩的分组头标的指令包括使得所述机器将一个IP安全(“IPSec”)协议应用于所述第一端到端被压缩的分组头标的指令。
20.一种包括一个在其上已经存储有指令的机器可访问的媒介的产品,当该指令由一个机器执行时,会使该机器:
接收包括一个第一端到端被压缩的分组头标和一个净荷的所述安全的被压缩的网络分组;
解密所述安全的被压缩的分组头标;以及
将一个第一鲁棒头标解压缩方案应用于所述第一端到端被压缩的分组头标从而恢复所述第一分组头标。
21.按照权利要求20中的产品,其中所述安全的网络分组还包括一个第二逐跳被压缩的分组头标。
22.按照权利要求21中的产品,其中所述指令还会使所述机器将一个第二鲁棒头标解压缩方案应用于所述第二逐跳被压缩的分组头标从而恢复所述第二分组头标。
23.按照权利要求22中的产品,其中所述第一鲁棒头标解压缩方案和第二个鲁棒头标解压缩方案是鲁棒头标压缩(“ROHC”)。
24.一种用于发送网络分组的系统,包括:
一个网络;
该网络上的一个源节点,所述源节点能够将一个第一鲁棒头标压缩方案应用于一个第一分组头标从而生成一个第一端到端被压缩的分组头标,所述源节点还能够将所述第一端到端被压缩的分组头标和一个净荷加密从而生成一个安全的被压缩的网络分组,进一步所述源节点还能够将所述安全的被压缩的网络分组在该网络上发送;以及
该网络上的一个目的地节点,所述目的地节点能够接收经过该网络的、来自源节点的所述安全的被压缩的网络分组,所述目的地节点还能够解密所述安全的被压缩的分组从而恢复所述第一端到端被压缩的分组头标和所述净荷,进一步所述源节点还能够将一个第一鲁棒头标解压缩方案应用于所述第一端到端被压缩的分组头标从而恢复所述第一分组头标。
25.按照权利要求24中的系统,其中所述第一鲁棒头标压缩方案和第一鲁棒头标解压缩方案是鲁棒头标压缩(“ROHC”)。
26.按照权利要求25中的系统,其中所述源节点还能够将一个第二鲁棒头标压缩方案应用于一个第二分组头标从而生成一个第二逐跳被压缩的分组头标。
27.按照权利要求26中的系统,其中所述目的地节点还能够将一个第二鲁棒头标解压缩方案应用于所述第二逐跳被压缩的分组头标从而恢复所述第二个分组头标。
28.一种路由一个安全的被压缩的网络分组的方法,包括:
接收来自一个第一网络节点的所述安全的被压缩的网络分组,所述安全的被压缩的网络分组包括一个逐跳被压缩的分组头标;
将一个鲁棒头标解压缩方案应用于所述逐跳被压缩的分组头标从而恢复一个分组头标;
将一个鲁棒头标压缩方案应用于所述分组头标从而重新生成所述安全的被压缩的网络分组,该网络分组包括逐跳被压缩的分组头标;以及
将所述安全的被压缩的网络分组发送到一个第二网络节点。
29.按照权利要求28中的方法,其中所述安全的被压缩的网络分组从一个源节点被发送到一个目的地节点并且所述第一节点和第二节点是所述源节点和目的地节点之间的中间节点。
30.按照权利要求28中的方法,其中所述鲁棒头标压缩方案和鲁棒头标解压缩方案是鲁棒头标压缩(“ROHC”)。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/302,351 US7386723B2 (en) | 2002-11-22 | 2002-11-22 | Method, apparatus and system for compressing IPSec-protected IP packets |
US10/302351 | 2002-11-22 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1503527A true CN1503527A (zh) | 2004-06-09 |
CN1503527B CN1503527B (zh) | 2010-09-29 |
Family
ID=32324752
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN03158742.9A Expired - Fee Related CN1503527B (zh) | 2002-11-22 | 2003-09-22 | 压缩安全协议保护的网际协议分组的方法、设备和系统 |
Country Status (2)
Country | Link |
---|---|
US (1) | US7386723B2 (zh) |
CN (1) | CN1503527B (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100353727C (zh) * | 2004-07-16 | 2007-12-05 | 中国科学院计算技术研究所 | 一种鲁棒的IPv6头部压缩方法 |
WO2010124472A1 (zh) * | 2009-04-30 | 2010-11-04 | 华为技术有限公司 | 一种数据的传输方法、相关设备和通信系统 |
CN101663867B (zh) * | 2007-04-26 | 2012-07-11 | 微软公司 | 在维持端点到端点认证的同时压缩数据分组 |
CN101543001B (zh) * | 2006-11-30 | 2016-03-09 | 艾利森电话股份有限公司 | 处理分组的方法、终端和归属代理 |
CN106656909A (zh) * | 2015-10-28 | 2017-05-10 | 瑞昱半导体股份有限公司 | 传输装置及其传输方法 |
CN106921618A (zh) * | 2015-12-25 | 2017-07-04 | 瑞昱半导体股份有限公司 | 接收装置及其封包处理方法 |
Families Citing this family (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7613185B2 (en) | 2004-03-17 | 2009-11-03 | Verizon Corporate Services Group Inc. | Packet header compression for lossy channels |
US8782405B2 (en) * | 2004-03-18 | 2014-07-15 | International Business Machines Corporation | Providing transaction-level security |
GB2414367B (en) * | 2004-05-20 | 2009-03-04 | Vodafone Plc | Data transmission |
US7657737B2 (en) * | 2005-02-28 | 2010-02-02 | International Business Machines Corporation | Method for mapping an encrypted https network packet to a specific url name and other data without decryption outside of a secure web server |
US20060268820A1 (en) * | 2005-05-19 | 2006-11-30 | Heikki Mahkonen | IP header compression with IPv6 mobile node |
EP2005640B1 (en) * | 2006-04-12 | 2020-03-11 | Telefonaktiebolaget LM Ericsson (publ) | Plural telecommunications functions having sharing transaction(s) |
US8189586B2 (en) * | 2006-04-12 | 2012-05-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Plural telecommunications functions having sharing transaction(s) |
US20070242703A1 (en) * | 2006-04-12 | 2007-10-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Binding/combining of plural telecommunications functions |
US8583929B2 (en) * | 2006-05-26 | 2013-11-12 | Alcatel Lucent | Encryption method for secure packet transmission |
US20080065890A1 (en) * | 2006-09-11 | 2008-03-13 | Motorola, Inc. | Secure support for hop-by-hop encrypted messaging |
US8284943B2 (en) * | 2006-09-27 | 2012-10-09 | Certes Networks, Inc. | IP encryption over resilient BGP/MPLS IP VPN |
TWI364953B (en) * | 2006-12-19 | 2012-05-21 | Innovative Sonic Ltd | Method and apparatus for recovering protocol error in a wireless communications system |
CN101364980B (zh) * | 2007-08-10 | 2012-06-20 | 华为技术有限公司 | 建立头压缩通信的方法及系统、头压缩策略功能实体 |
US8488582B2 (en) * | 2008-06-12 | 2013-07-16 | Alcatel Lucent | Minimal GAN RTP packet length via multi-level header compression |
US9276663B2 (en) | 2009-04-17 | 2016-03-01 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
WO2010121216A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | System, method and apparatus for providing end-to-end layer 2 connectivity |
WO2010121219A2 (en) | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Core-based satellite network architecture |
US8379613B2 (en) * | 2009-04-17 | 2013-02-19 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
US8274981B2 (en) * | 2009-04-17 | 2012-09-25 | Viasat, Inc. | Acceleration through a network tunnel |
WO2010121215A1 (en) | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Layer-2 extension services |
WO2010121217A1 (en) | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Mobility across satellite beams using l2 connectivity |
US8427999B2 (en) * | 2009-04-17 | 2013-04-23 | Viasat, Inc. | Multi-satellite architecture |
US20110016313A1 (en) * | 2009-07-15 | 2011-01-20 | Qualcomm Incorporated | HEADER COMPRESSION FOR TUNNELED IPsec PACKET |
WO2011083567A1 (ja) * | 2010-01-06 | 2011-07-14 | 富士通株式会社 | 負荷分散システム及びその方法 |
EP3016432B1 (en) * | 2014-10-30 | 2018-07-04 | Vodafone IP Licensing limited | Content compression in mobile network |
US10911413B2 (en) * | 2015-09-16 | 2021-02-02 | Oracle International Corporation | Encapsulating and tunneling WebRTC traffic |
US10986076B1 (en) * | 2016-09-08 | 2021-04-20 | Rockwell Collins, Inc. | Information flow enforcement for IP domain in multilevel secure systems |
GB201710168D0 (en) | 2017-06-26 | 2017-08-09 | Microsoft Technology Licensing Llc | Introducing middleboxes into secure communications between a client and a sever |
WO2019061168A1 (en) * | 2017-09-28 | 2019-04-04 | Qualcomm Incorporated | PRIORITIZING DATA PACKETS WHEN DYNAMIC COMPRESSION IS ON |
US10419408B1 (en) * | 2018-09-24 | 2019-09-17 | Karamba Security | In-place authentication scheme for securing intra-vehicle communication |
US11343715B1 (en) * | 2020-08-23 | 2022-05-24 | Rockwell Collins, Inc. | Header compression for network |
CN113329442B (zh) * | 2021-04-20 | 2022-02-11 | 北京连山科技股份有限公司 | 一种通用的多链路载荷压缩与解压缩方法和系统 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6092120A (en) * | 1998-06-26 | 2000-07-18 | Sun Microsystems, Inc. | Method and apparatus for timely delivery of a byte code and serialized objects stream |
US7031666B2 (en) * | 2001-03-28 | 2006-04-18 | Qualcomm Incorporated. | Method and apparatus for header compression in a wireless communication system |
US6909702B2 (en) * | 2001-03-28 | 2005-06-21 | Qualcomm, Incorporated | Method and apparatus for out-of-band transmission of broadcast service option in a wireless communication system |
US7209491B2 (en) * | 2002-06-28 | 2007-04-24 | Nokia Corporation | Method and system for transmitting data in a packet based communication network |
-
2002
- 2002-11-22 US US10/302,351 patent/US7386723B2/en not_active Expired - Fee Related
-
2003
- 2003-09-22 CN CN03158742.9A patent/CN1503527B/zh not_active Expired - Fee Related
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100353727C (zh) * | 2004-07-16 | 2007-12-05 | 中国科学院计算技术研究所 | 一种鲁棒的IPv6头部压缩方法 |
CN101543001B (zh) * | 2006-11-30 | 2016-03-09 | 艾利森电话股份有限公司 | 处理分组的方法、终端和归属代理 |
CN101663867B (zh) * | 2007-04-26 | 2012-07-11 | 微软公司 | 在维持端点到端点认证的同时压缩数据分组 |
WO2010124472A1 (zh) * | 2009-04-30 | 2010-11-04 | 华为技术有限公司 | 一种数据的传输方法、相关设备和通信系统 |
CN102282808A (zh) * | 2009-04-30 | 2011-12-14 | 华为技术有限公司 | 一种数据的传输方法、相关设备和通信系统 |
CN102282808B (zh) * | 2009-04-30 | 2013-11-06 | 华为技术有限公司 | 一种数据的传输方法、相关设备和通信系统 |
CN106656909A (zh) * | 2015-10-28 | 2017-05-10 | 瑞昱半导体股份有限公司 | 传输装置及其传输方法 |
CN106656909B (zh) * | 2015-10-28 | 2020-02-28 | 瑞昱半导体股份有限公司 | 传输装置及其传输方法 |
CN106921618A (zh) * | 2015-12-25 | 2017-07-04 | 瑞昱半导体股份有限公司 | 接收装置及其封包处理方法 |
CN106921618B (zh) * | 2015-12-25 | 2019-11-29 | 瑞昱半导体股份有限公司 | 接收装置及其封包处理方法 |
Also Published As
Publication number | Publication date |
---|---|
US20040103277A1 (en) | 2004-05-27 |
US7386723B2 (en) | 2008-06-10 |
CN1503527B (zh) | 2010-09-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1503527B (zh) | 压缩安全协议保护的网际协议分组的方法、设备和系统 | |
CN109565510B (zh) | 使用随机加密密码本加密法进行安全通信的系统和方法 | |
KR101357026B1 (ko) | 무선 네트워크들을 위한 공중-인터페이스 애플리케이션 층보안 | |
US7574736B2 (en) | System and method for efficiently transferring media across firewalls | |
US6272633B1 (en) | Methods and apparatus for transmitting, receiving, and processing secure voice over internet protocol | |
US7581094B1 (en) | Cryptographic checksums enabling data manipulation and transcoding | |
JP5392102B2 (ja) | 無線ネットワークにおいてオーバヘッドを低減する装置及び方法 | |
US20020129243A1 (en) | System for selective encryption of data packets | |
JP2005532700A (ja) | 安全なスケーラブルデータストリーミング用の記憶デバイス | |
US8189586B2 (en) | Plural telecommunications functions having sharing transaction(s) | |
US11349820B2 (en) | Selective encryption of tunneled encrypted traffic | |
US20070242703A1 (en) | Binding/combining of plural telecommunications functions | |
US10313486B2 (en) | Optimizing transfer of fragmented packetized data | |
JP2005528631A (ja) | 安全なスケーラブルデータストリーミング用の符号化/暗号化デバイス | |
JP2005531938A (ja) | 安全なスケーラブルデータストリーミング用のパケット化デバイス | |
US7426636B1 (en) | Compact secure data communication method | |
Räsänen et al. | Open-source RTP library for end-to-end encrypted real-time video streaming applications | |
CN1383697A (zh) | 移动通信系统 | |
CN117081840B (zh) | 安全套接层通信方法、装置、专用数据处理器及介质 | |
CN101421973B (zh) | 具有共享事务处理的多个远程通信功能的方法和装置 | |
JP2003244194A (ja) | データ暗号装置及び暗号通信処理方法及びデータ中継装置 | |
CN101350824A (zh) | 一种数据传输方法、装置和系统 | |
JP2007201973A (ja) | データ送受信システム、暗号化情報共有方法、データ送信装置、及びデータ受信装置 | |
Ertekin et al. | Integration of robust header compression over IPsec security associations | |
CN117201232A (zh) | 一种高性能IPSec VPN方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20100929 Termination date: 20210922 |